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Ole- Johan Dahl 




Preface 



After Ole-Johan’s retirement at the beginning of the new millennium, some of 
us had thought and talked about making a “Festschrift” in his honor. When 
Donald Knuth took the initiative by sending us the first contribution, the pro- 
cess began to roll! In early 2002 an editing group was formed, including Kristen 
Nygaard, who had known Ole-Johan since their student days, and with whom 
he had developed the Simula language. Then we invited a number of prominent 
researchers familiar with Ole-Johan to submit contributions for a book honor- 
ing Ole-Johan on the occasion of his 70th birthday. Invitees included several 
members of the IFIP 2.3 working group, a forum that Ole-Johan treasured and 
enjoyed participating in throughout his career. In spite of the short deadline, the 
response to the invitations was overwhelmingly positive. 

The original idea was to complete the book rather quickly to make it a gift 
he could read and enjoy, because by then he had had cancer for three years, 
and his health was gradually deteriorating. Kristen had been regularly visiting 
Ole-Johan, who was in the hospital at that time, and they were working on their 
Turing award speech. Ole-Johan was gratified to hear about the contributions 
to this book, but modestly expressed the feeling that there was no special need 
to undertake a book project on his behalf. Peacefully accepting his destiny, Ole- 
Johan died on June 29, 2002. Kristen, who was 5 years older than Ole-Johan, 
was still very active. Quite surprisingly, he died 6 weeks later of a sudden heart 
attack. During this short period, Norway lost its two greatest computer scientists. 

We are grateful to all who helped with the book, especially all the contrib- 
utors and the anonymous referees. Credit is due to Ellef Gjelstad, who helped 
with the preparation of the manuscript. 



Olaf Owe, 
Stein Krogdahl, 
Tom Lyche 



University of Oslo 
December 2003 
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A Biography of Ole-Johan Dahl 



Olaf Owe, Stein Krogdahl, and Tom Lyche 
Department of Informatics, University of Oslo 



On 12 October 1931, Ole-Johan Dahl was born to the family of a ship captain in 
Mandal, the southernmost city of Norway. In 1952, three years after beginning 
his studies at the University of Oslo, he was introduced to computers at the Nor- 
wegian Defense Research Establishment (NDRE) where he fulfilled his military 
service obligation. Jan V. Garwick was responsible for the field of mathematical 
analysis and calculations, and Ole-Johan was placed in the “computing room” 
led by Garwick’s assistant, Kristen Nygaard. It is quite likely that, in this set- 
ting, Garwick, Nygaard and Dahl were the first in Norway to develop programs 
on “large” digital computers. In the years to come, NDRE cultivated a scientific 
collaboration with the pioneering computer group at the University of Manch- 
ester and the electronics company Ferranti. As a result of this tie, NDRE got 
the first version of Ferranti’s Mercury computer in 1957. 

Ole-Johan’s next project was to develop and implement a “high level” lan- 
guage for numerical computation, called MAG (Mercury Automatic Goding). 
While Kristen changed focus to the area of operations research in the mid-1950s, 
Ole-Johan became Garwick’s main collaborator. Together they formed the first 
real programming group in Norway. 

In 1958, Ole-Johan completed the Gandidatus Realium degree at the Uni- 
versity of Oslo in mathematics. His thesis entitled “Multiple Index Gountings 
on the Ferranti Mercury Gomputer” [94] , was formally in the area of numerical 
analysis, but actually in computer science and programming, a field that had 
not yet emerged. In fact, he was one of the first to acquire a relevant and modern 
education in computer science. 

In 1960 Kristen had become research director at the Norwegian Gomputing 
Genter (NGG). He decided to make an attempt solve two main problems in 
operations research, namely, the lack of concepts and language for description 
and communication about large and complex systems, and the lack of a specialized 
programming language for simulation tasks. Realizing that he could not do this 
by himself, he looked to Ole-Johan, a specialist in programming language, as the 
obvious collaborator. 

They started working together in 1961, and in 1963 Ole-Johan joined Kris- 
ten full-time at NGG. Together they created the Simula 1 language (1961-1965) 
and Simula 67 (1965-1968), introducing the concepts of class, subclass and in- 
heritance, virtual binding of operations, and dynamic creation of objects. The 
Simula concept of quasi-parallelism reflected that objects may in principle be 
independent processes running in parallel. Implicit forms of information hiding, 
through the subclass mechanism, were later also complemented by explicit forms 
of information hiding. 



O. Owe et al. (Eds.): From OO to FM (Dahl Festschrift), LNCS 2635, pp. 1-7, 2004. 
@ Springer- Verlag Berlin Heidelberg 2004 
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These concepts, which constitute what today is called object-orientation, 
have greatly influenced modern programming languages, programming method- 
ology and modeling languages, including UML. The class related concepts in 
Simula were clearly ahead of their time; it took some 20 years until they gained 
understanding and popularity. Languages such as Smalltalk, Beta, C-|— 1-, Eiffel, 
Java, and C#, have directly adopted Simula’s fundamental concepts about ob- 
jects and classes. Object-orientation is today the dominant style of programming, 
description, and modeling. 

To quote Bjarne Stoustrup: “Simula isn’t just an innovative programming 
language. From the beginning it came with a philosophy of design based on 
modeling that has had impact far beyond the realm of programming and pro- 
gramming languages.” The object-oriented philosophy also underlies the modern 
use of windows and the graphical interfaces that we all use. 

How could Ole-Johan and Kristen, at such an early stage, design a language 
with all the mechanisms that today form the “object-oriented” paradigm for 
system development? An important part of the answer is obviously that they 
were extraordinary talented researchers in the held, and with rather different 
perspectives and personalities, which frequently led to confrontations and heated 
discussions. There is a famous story illustrating their style of working: A new 
employee at NCC came worriedly running down to the receptionist and cried 
out: “We must do something! There are two men fighting upstairs in front of 
the blackboard.” The receptionist listened for a moment, and replied: “No don’t 
worry. It is just Kristen and Ole-Johan discussing Simula!” 

In addition, it was probably very fortunate that they first designed a lan- 
guage for simulation (Simula 1), and later generalized the concepts in a general 
purpose language (Simula 67). Ole-Johan has expressed it this way: “A reason 
for this may be that in developing a complicated simulation model it is useful 
to decompose it in terms of ‘objects’, and to have an explicit mapping from ex- 
ternal objects to program constructs. A natural way of developing real systems 
is not much different.” Kristen emphasized that an essential motivation behind 
Simula was system description, and the need for a language to model real world 
concepts. 

The final recognition of Ole-Johan and Kristen as the founders of object ori- 
entation has been established through two prestigious awards, both given during 
their last year of life: In November 2001, they were awarded the IEEE John von 
Neumann Medal “for the introduction of the concepts underlying object-oriented 
programming through the design and implementation of Simula 67,” and in 
February 2002, they were given the A. M. Turing Award by the ACM “for ideas 
fundamental to the emergence of object-oriented programming, through their 
design of the programming languages Simula 1 and Simula 67” [tribute] . 

Earlier, in June 2000, they were awarded Honorary Fellowships for “their 
originating of object technology concepts” by the Object Management Group, 
the main international standardization organization within object-orientation. 
In August 2000 they were appointed Commanders of the Order of Saint Olav 
by the King of Norway (one of the highest national awards), and in 1999 they 
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became the first to receive the Rosing Honorary Prize, awarded by the Norwegian 
Data Association for exceptional professional achievements. Both were elected 
members of the Norwegian Academy of Science. Ole-Johan was also a member 
of IFIP Working Group 2.3 and of Academia Europaea, and he received an 
honorary doctorate from the University of Lund, Sweden. 

A characteristic of Ole-Johan as a researcher was his quest for simplicity, 
elegance, and purity rather than ad hoc solutions with their associated exceptions 
and compromises. This is reflected in the class concept of Simula. From an 
educational point of view, its elegance, generality and simplicity make Simula 
well suited for teaching object orientation. 

We include below a version of the last paper Ole-Johan wrote [36]^, which 
provides a detailed summary of the research leading up to Simula, as well as 
afterthoughts and viewpoints of its cultural impact. Other sources of information 
on the development of Simula are [23] , and more recently [Hol94, Kro03, B6s03] . 



Research at the University of Oslo 

In 1968 Ole-Johan was invited to be a full professor to create the discipline of 
computer science at the University of Oslo. He spent enormous efforts building 
up a curriculum in computer science in the late 1960s, writing textbooks at night 
while teaching during the day, and supervising up to 20 graduate students at 
a time. For 10 years from 1968 he was the only professor in computer science 
in Oslo. For many years, he had only one lecturer and a few research assistants 
helping him. The courses he designed met the highest international standards 
of the time and for many years to come. Most of the courses were offered for 20 
years or more with only minor changes; some are still being taught. 

After beginning his career at the university, Ole-Johan deliberately stopped 
working on further development of Simula as such. In his new position he felt 
that it was essential to build up computer science to be an accepted academic 
discipline, and establish a theoretical foundation for basic concepts of computer 
science and programming languages. He made important advances in program- 
ming methodology, introducing techniques for program structuring and concep- 
tual modeling, based on the experiences of the design and implementation of 
Simula. Early works in this direction include the papers [1,4, 10, 13, 14, 16, 17, 
63] with his work on Hierarchical Program Structures as the best known and 
most influential. 

Inspired by Tony Hoare’s logic for program reasoning [Hoa69], he contin- 
ued research in the area of program architecture, programming and specification 
languages, as well as verification methods and techniques. Most of this work is 
related to the area of formal methods, where the idea is to use mathematical 
methods to specify, develop and reason about programs. Because of his computer 
science background and education, his theoretical work was accompanied by con- 
cern for practical relevance and usefulness. Exploiting the advantages of both, he 
advocated combined use of top-down development and bottom-up development. 

References labeled with numbers refer to the bibliography of Ole-Johan. 
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This led to research on abstract data types, a concept inspired by the class 
concept of Simula and Tony Hoare’s paper entitled Proof of correctness of data 
representation [Hoa72]. In particular, Ole-Johan focused on generator induc- 
tion, inspired by the work of John Guttag and Jim Horning, subtyping, inspired 
by Simula’s subclass mechanism and by the work on order sorted algebra, and 
integration of applicative and imperative class-based reasoning. Based on mecha- 
nizable evaluation and reasoning, he developed a theory for “constructive” types 
and subtypes centered around a long term project, called Abstraction Building, 
Education Language (ABEL), which served as a research testbed and source 
of student projects [5,21,25,26,33,34,43,44,46,53], and resulted in several dr. 
sclent theses supervised by Ole-Johan [Owe80,Nos84,Mel86,Lys91j. 

Ole-Johan was teaching formal methods, and their practical use for 30 years. 
He believed that computer science students should know the principles of pro- 
gram reasoning, and that this would make them better programmers even with- 
out performing detailed verification. The course work has resulted in the book, 
Verifiable Programming [5], which includes much of his own research and re- 
sults. He supervised a large number of students, ten of whom became university 
professors. 

Formal Methods, Object-Orientation, and Concurrency 

Work towards the understanding and formalization of what is now called object- 
orientation, was carried out already in the early 1970s [15, 18], and with the thesis 
of Arne Wang, one of Ole- Johan’s first students [Wan74]. 

Ole-Johan’s early approach to reasoning about object-oriented systems builds 
on the idea of limiting direct access to attributes of an object from outside, either 
disallowing all remote variable access or allowing access to some variables (seen as 
an abbreviation for implicit read and write operations). This means that one can 
give local invariants in a class and prove that the class invariant is established 
and maintained by looking at the text of the class itself and possibly super- 
classes. When subclassing is restricted so that super-invariants are respected, 
reasoning about objects can be done without looking at the global state space: 
Hoare style reasoning can be done locally in each class. 

Early on it was recognized that this kind of class-based reasoning was fruitful 
for the Monitor concept of Hoare [Hoa74] and for aspects of operating systems 
concerning process control. The co-routine and monitor papers were part of this 
research direction [15,18,19,20,21,29,35,64] and the thesis of Stein Gjessing, 
who had been supervised by Ole-Johan [Gje83]. 

In contrast to those object-oriented approaches where “everything is an ob- 
ject”, Ole-Johan believed in object classes side by side with data types. Ole- 
Johan’s view was that objects should reflect mutable data structures, handled 
by references, and data types should reflect immutable, but copyable, data [28]. 
This called for user defined data types. In ABEL, a functional sublanguage was 
defined for definition of abstract data types, whereas classes were defined in 
an imperative style. Thus Ole-Johan considered functional programming as a 
complement to object-oriented programming rather than a competitor. 



A Biography of Ole-Johan Dahl 



5 



According to the original ideas of Simula, an object would in general have 
its own activity, as well as data and procedures. Objects with activity were 
reflecting “independent processes”, and objects without activity (but still with 
data and procedures) were called passive. In Simula 67 these ideas were realized 
by allowing objects to be co-routines, the natural way at that time to imitate 
concurrent processes and a useful simulation mechanism. In today’s world a 
natural adaptation would be to let objects be concurrent processes, and one 
would obtain a distributed system by a set of objects running in parallel and 
interacting by remote method calls (only). This is the approach taken in Ole- 
Johan’s later works. See for instance [26,36]. 

Ole-Johan’s work on abstract specification of concurrent objects by means of 
histories presents a techniques for “black box” interface specification of process 
classes. The abstract state of a concurrent object is represented by its com- 
munication history, i.e., the trace of all visible communication events involving 
the object, such as method calls. As the abstract state at any given time is re- 
flected by a finite history, Ole-Johan developed specification techniques based 
on finite traces, and a central idea was to use right-append as a trace gener- 
ator in order to describe new actions in terms of the current history, thereby 
avoiding recursive process definitions as found e.g. in CSP. Reasoning about 
concurrent objects in terms of such histories is compositional and integrates 
well with object-orientation. Ole-Johan developed a style of history specification 
where specifications of a certain form can easily be refined into an imperative 
object-oriented implementation. The use of histories was initiated in the early 
1970s and remained an important research topic for him throughout the 1990s 
[21,22,26,41,58]. When he retired, Ole-Johan was writing a book on concur- 
rency based on research in connection with a course on concurrency and process 
control [69,54]. 

The above principles for object-oriented programming, specification, and rea- 
soning, constitute what we may call “the Dahl School.” A further introduction 
is given in the paper by Johnsen and Owe in this volume. 



International Visits 

Due to Ole-Johan, several prominent researchers visited Oslo. In particular we 
mention the one year stay of Donald Knuth from Stanford University in 1972 to 
1973. Knuth had a great impact on the computer science development in Oslo 
at an early and crucial period in time. 

Knuth, who immediately understood the benefits of the Simula ideas, gave 
up work on his own simulation language (SOL), and became a supporter of Sim- 
ula. He could have made Simula quite well-known by teaching it at Stanford, but 
when asking for a inexpensive compiler for academic use at Stanford, he was un- 
fortunately turned down by NCC (despite the strong arguments of both Kristen 
and Ole-Johan, who fully understood the importance of this opportunity). 

In the late 1970s Reiji Nakajima, a post doc at that time, made a one year 
visit to Oslo, which led to a number of interesting discussions around abstract 
data types and ABEL. In the early 80s, Neelam Soundarajan visited Oslo for 
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a year, working together with Ole-Johan on reasoning with histories. Ole-Johan 
enjoyed this cooperation very much, appreciating Neelam’s clarity. Neelam came 
for a second year in the early 1990s. Zhenjia Lei, University of Xi’an also visited 
Ole-Johan, which resulted in a return visit by Ole-Johan in Xi’an in the mid- 
1990s. Apart from this visit, Ole-Johan had only one sabbatical leave during his 
career, which was spent at Stanford University in the late 1970s. 

Ole-Johan also enjoyed the many shorter visits by a large number of scientists, 
including Tony Hoare, Hans Langmaack, Dines Bjprner, Eugene Kindler, Cliff 
Jones, Manfred Broy, David Luckham, Jean-Pierre Jouannaud, Pierre Lescanne, 
and Willem-Paul de Roever, most of whom also enjoyed music evenings and 
dinners in Ole-Johan’s home. 



Personal Interests 

Ole-Johan was a music lover and an excellent amateur pianist. In fact, he was 
one of the best “prima vista” amateur pianists in Norway. He knew the world 
of classical music well, and that of chamber music in particular. Much of his 
free time was filled by music, and he was a central member of the Board of Oslo 
Quartet Association and a driving force behind the yearly chamber music courses 
at the Nansen School in Lillehammer. He regularly arranged house concerts 
at the department, often playing together with visitors who happened to be 
musicians, or with his wife or daughter. 

In addition he enjoyed and excelled in many kinds of games including chess 
and bridge, and spent much time as a student pursuing these interests. At con- 
ferences he was known for his skills in classical billiards (3 balls) in addition to 
the piano. A personal bibliography is written by his wife [Dah03]. 
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17. Programming Discipline. O.-J. Dahl. In: Proceedings of the 1974 CERN 
School of Computing, Godysund, Aug. 1974. GERN Report 74-23, Geneva, 
pages 426-435. 
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37. Analysis of an Algorithm for Priority Queue Administration. Arne Jonassen 
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38. An Approach to Correctness Proofs of Semicoroutines. O.-J. Dahl. Re- 
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39. Can Program Proving be Made Practical? O.-J. Dahl. Research Report in 
Informatics no. 33, 1978 (57 pages) Lectures presented at the EEC-CREST 
course on Programming Foundations, Toulouse 1977 (revised May 1978). 
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44. A Presentation of the Specification and Verification Project ABEL. 
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ISBN 82-90230-89-3. Also in the proceedings of the 3. Verification Work- 
shop, Watsonville, CA, Feb. 1985. 

45. Specification and Reasoning about Discrete Simulation Models: A 
Case Study. O.-J. Dahl. Research Report no. 94, 1985 (10 pages) 
ISBN 82-90230-93-1. Lecure at the IMACS World Congress on System Sim- 
ulation and Scientific Computation, Oslo, Aug. 1985. 

46. Preliminary Report on the Specification and Programming Language 
ABEL. O.-J. Dahl, Dag F. Langmyhr, O. Owe. Research Report no. 106, 
1986 (86 pages) ISBN 82-7368-006-1 

47. Object Oriented Specification. O.-J. Dahl. Research Report no. 108, 1987 
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48. Generator Induction in Order Sorted Algebras. O.-J. Dahl and O. Owe. 
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O.-J. Dahl. Research Report no. 192, 1994 ISBN 82-7368-102-5 
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O.-J. Dahl. Dept, of Mathematics, 1970 (46 pages) (In Norwegian). 
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1988, Part II and HI 1990. Compendium 42, Dept, of Informatics (153 
pages). 
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69. Parallell programmering (Parallel Programming). O.-J. Dahl. Com- 
pendium 45, Dept, of Informatics (69 pages), Revised Aug. 1995 (In Nor- 
wegian). Kompendium 46, Aug. 1996 (In Norwegian). 

70. Stochastic Simulation Modelling. O.-J. Dahl. Compendium 69, Dept, of 
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71. Preliminary Presentation of the Simula Language and some Exam- 
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72. SIMSCRIPT Implementation. Vic Bell and O.-J. Dahl. NCC Doc. (31 
pages), Nov. 1963. 

73. The SIMULA Storage Allocation Scheme. O.-J. Dahl. NCC Doc. 162, Nov. 
1963 (9 pages) 

74. SIMULA Status Report. O.-J. Dahl. NCC Doc. 1.1, 1964 (10 pages) 

75. The SIMULA Data Structures. O.-J. Dahl. NCC Doc. March 1964 
(23 pages) 

76. The SIMULA Language: Specifications 17 March 1964. O.-J. Dahl and 
K. Nygaard. NCC Doc. March, 1964 (30 pages) 

77. The SIMULA Project: Technical Progress Report 1. O.-J. Dahl and K. Ny- 
gaard. NCC Doc. July 1, 1964 (7 pages) 

78. SIMULA status report. O.-J. Dahl. NCC Doc. 1.10, 1964 (24 pages) 

79. SIMULA - A Language for Programming and Description of Discrete Event 
Systems: Introduction and User’s Manual. O.-J. Dahl and K. Nygaard. 
NCC Publ. no. 11, May 1965 (103 pages). Revised versions: 1966. Ill, 108 
pages. 5th ed. NCC, 1967 (124 pages) 

80. Basic Concepts of SIMULA - an ALGOL Based Simulation Language. 
O.-J. Dahl and K. Nygaard. NCC Doc., 1965 (17 pages) 

81. SIMULA, an ALGOL Based Simulation Language. O.-J. Dahl and K. Ny- 
gaard. NCC Doc., April 1966 (26 pages) * 

82. Discrete Event Simulation Languages: Lectures Delivered at the NATO 
Summer School, Villard-de-Lans, Sept. 1966. O.-J. Dahl. NCC Doc., 1966 
(63 pages) * 

83. SIMULA: Simula Tracing System. O.-J. Dahl, B. Myhrhaug and K. Ny- 
gaard. NCC Doc., 1966. 

84. Class and Subclass Declarations. O.-J. Dahl and K. Nygaard. NCC Publ. 
no. 93, (Presented at IFIP Working Conference on Simulation Languages, 
Lysebu, Oslo, May 1967). March 1967 (17 pages) * 

85. SIMULA 67 Common Base Proposal. O.-J. Dahl and K. Nygaard. NCC 
Doc., May 1967 (10 pages) 

86. Proposals for Consideration by the SIMULA 67 Common Base Conference. 
O.-J. Dahl and K. Nygaard. NCC Doc., June 1967. 

87. SIMULA 67 Common Base Definition. O.-J. Dahl and K. Nygaard. NCC 
Doc., June 1967 (31 pages). 
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88. SIMULA 67 Common Base Language. O.-J. Dahl, B. Myhrhaug, K. Ny- 
gaard. NCC Publ. S-2, 1968 (141 pages). 

Revised editions: (1970, 145 pages, SIMULA information: NCC Publ. S- 

22) . (1982, 127 pages, NCC Publ. no. 725). (1984, 172 pages, NCC Publ. 
no. 743). ISBN 82-539-0225-5 ^ 

89. Some Uses of the External Class Concept in SIMULA 67. O.-J. Dahl, 
B. Myhrhaug, K. Nygaard. NCC Doc., 1968. (Presented at the NATO 
sponsored conference on Software Engineering, Garmisch, Germany, Octo- 
ber 1968) 

90. SIMULA 67 - Basic Information. O.-J. Dahl and K. Nygaard. NCC Publ. 
no. S-3, 1968 (12 pages). 

91. SIMULA 67- Implementation Guide. O.-J. Dahl, B. Myhrhaug. NCC Publ. 
no. S-9, 1969. Rev. March 1973, NCC Publ. no. S-47 (146 pages). 

92. The Development of the SIMULA Languages. K. Nygaard and O.-J. Dahl. 
NCC Doc. (Publication 603), 1978 (28 pages) ISBN 82-539-0072-4 (Note: 
includes a bibliography.) * 

Reports from the Norwegian Defense Research Establishment 
(NDRE), Kjeller, Norway 

93. An Automatic Coding Scheme for the Ferranti MERCURY Computer. 
O.-J. Dahl. NDRE Report IR-F-286, 1956. 

94. Multiple Index Countings on the Ferranti MERCURY Computer. O.-J. 
Dahl. Norwegian Defense Research Establishment, 1957. (NDRE Report 

23) & Cand real thesis. University of Oslo, Dept, of Mathematics, 1957. 

95. Programmer’s Handbook for the Ferranti MERCURY Computer Frederic 
at the Norwegian Defense Research Establishment. O.-J. Dahl, Jan V. Gar- 
wick. NDRE. 2. edition published by Merkantile Trykkeri, Oslo, 1958. 3. 
edition, NDRE, 1962 (117 pages). 

96. Mac Bulletin I. O.-J. Dahl. NDRE report (S-15), 1960 (10 pages)^ 

97. Mac Bulletin II. O.-J. Dahl. NDRE report (S-17), 1960 (3 pages) 

98. Mac Bulletin V: Macros. O.-J. Dahl NDRE report (S-57), 1963 (13 pages) 

Video Recorded Talks 

99. ACM SIGPLAN History of Programming Languages Conference, January 
1978, Los Angeles. SIMULA Session. Speakers: Nygaard and Dahl. 1 video- 
tape (VHS) (60 min), ACM, 1980. 

100. The talk given at Software Pioneers Conference, Bonn, June 2001 (supplied 
with the book [36] above). 

101. Introduction to SIMULA (talk given in Norwegian), to be available through 
the department homepage: http://www.ifi.uio.no/. 

^ All versions of the common base language definition assume knowledge of Algol 60. 
A final and complete version of the SIMULA 67 language definition without this 
assumption is found in: Standard SIMULA, as approved by the SIMULA Standards 
Group Aug. 26, 1986. (176 pages) ISBN 91-7162-234-9. 

^ MAC was an acronym for MERCURY Automatic Coding, a high level programming 
language for the MERCURY computer, and a compiler. 
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Abstract. The development of the programming languages Simula I 
and Simula 67 is briefly described. An attempt is made also to explain 
the cultural impact of the languages, in particular the object oriented 
aspects. 



1 Introduction 

In 1962 Kristen Nygaard, KN, initiated a project for the development of a 
discrete event simulation language, to be called Simula. At the time KN was 
the director of research at the Norwegian Computing Center, NCC, (a semi- 
governmental institution). KN also served as the administrative leader for the 
duration of the project. This required much creative manipulation in an envi- 
ronment that outside the NCC was largely hostile. The language development 
proper was a result of a close cooperation between KN and the author, OJD, 
whereas implementation considerations were mainly the responsibility of the lat- 
ter. 

We were both fostered at the Norwegian Defence Research Establishment in 
the pioneering group headed by Jan V. Gar wick, the father of Computer Science 
in Norway. But our backgrounds were nevertheless quite different. KN had done 
Monte Carlo computations calibrating uranium rods for a nuclear reactor and 
later operations research on military systems. OJD had developed basic software 
together with Garwick and designed and implemented a high level programming 
language. Our difference in background probably accounts for some of the success 
of the Simula project. 

The present paper mainly deals with language issues, including some thoughts 
on their possible cultural impact, especially on later programming languages. For 
other aspects of the project the reader is referred to [30]. 

Two language versions were defined and implemented. The first one, later 
called Simula I, was developed under a contract by UNIVAC. (UNIVAC wanted 
us to provide also a Fortran-based version, but that was abandoned because 
the block structure turned out to be essential to our approach.) It was up and 
running by the end of 1964. The second version, Simula 67, was sponsored 
by the NCC itself. It is a generalization and refinement of the former, fairly 
ambitious, intended mainly as a general purpose programming language, but 
with simulation capabilities. 

* An almost identical version of this paper has been published in Software pioneers, 
Springer, 2002. 



O. Owe et al. (Eds.): From OO to FM (Dahl Festschrift), LNCS 2635, pp. 15—25, 2004. 
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2 Simula I 

It was decided at an early stage that our language should be based on a well 
known one. Algol 60 was chosen for the following main reasons: 

— the block structure, 

— good programming security, 

— European patriotism. 

We realised that in order to profit from block structure in simulation models it 
would be necessary to break out of the strict LIFO regime of block instances in 
Algol. Thus, a new storage management system was developed based on a list 
structured free store, [3] . Then a useful simulation language could be defined by 
adding a few special purpose mechanisms to Algol 60: 

~ A procedure-like activity declaration giving rise to so called “processes”. 
Processes could range from record-like data structures to block structured 
programs executing in a coroutine-like fashion, [35], [9], over a simulated 
system time. 

— Explicit process pointers for dynamic naming and referencing. (The pointers 
were indirect through list forming “element” records.) 

— A mechanism for accessing, from the outside, quantities local to the outer- 
most block level of processes, designed so that the access security inherent 
in Algol would be maintained (the inspect construct). 

— A few run time mechanisms for the scheduling and sequencing of processes in 
system time, such as hold{. . .), suspending the calling process for a specified 
amount of system time. 

The following skeleton example could be a small fragment of a road traffic 
simulation. It is taken from the Simula I manual, [4], but slightly extended. 
It may serve to indicate the flavour of the language. 

SIMULA begin activity Car; 

begin real AO, TO, V; 

real procednre A; A := X0+V*{time—T0); 
procedure newV {V new); real Vnew; 

begin AO := A; TO := time; V := Vnew end; 

Car behaviour: ; /io/(i(<travel time>); 

end of Car; 
activity Police; 

begin ; inspect ^rocess> when Car do 

if A ^s within city> and U>50 then 

begin newV{50); <give fine> end; 

end of Police; 

main program: ^nitialise>; /ioW(<Simulation period>) 
end of simulation model; 
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The example shows that the idea of data objects with associated operators was 
under way already in 1965. According to a comment in [4] it was a pity that the 
variable attributes of a Car process could not be hidden away in a subblock. It 
would have required the accessing procedures to be hidden similarly. 

New processes would be generated explicitly. For programming security 
reasons, however, process deletions had to be implicit, in our implementation 
through reference counts and a last resort garbage collector. The bulk of the 
implementation effort therefore consisted in writing a new run time system 
for the Algol system provided by UNIVAC; the compiler extensions, on the 
other hand, were minimal. The “block prefix” SIMULA served to introduce 
the Simula I additions to Algol. Consequently any Algol program not containing 
that keyword would execute normally on our compiler. That was an important 
consideration in those days. 

A paper on Simula I was published in CACM 1966, [5]. It was also the main 
topic of lectures given by OJD at the NATO Summer School at Vilard-de-Lans 
the same year. The lectures were written up and published as a chapter of [6]. 

The language was used for simulation purposes as well as for teaching at 
several locations at home and abroad, also within the UNIVAC organization. 
A modified version was used for Burroughs computers. This was through the 
advocacy of Don Knuth and J. McNeley, the authors of SOL, another Algol-like 
simulation language. 

3 Simula 67 

In spite of the success of Simula I as a practical tool it became increasingly clear 
that the activity /process concepts, if stripped from all references to simulated 
time, would be useful for programming and system design in general. If possible 
the special purpose simulation facilities should be definable within the new 
language. Also the list processing facilities of Simula I would be useful, although 
we felt that the referencing mechanism should be simplified. 

At the Vilard-de-Lans Summer School Tony Hoare had put forth a proposal 
for “record handling” with record classes and subclasses, as well as record 
references restricted to, or “qualified by” , a given class or subclass by declaration. 
Attribute accessing was by dot notation, see [19], as well as [17] and [18]. 

We chose the terms “class” and “objects” of classes for our new Simula. The 
notion of subclass was especially appealing to us, since we had seen many cases 
of objects belonging to different classes having common properties. It would 
be useful to collect the common properties in a separate class, say C to be 
specialised differently for different purposes, possibly in different programs. The 
solution came with the idea of class prefixing: using C as a prefix to another 
class, the latter would be taken to be a subclass of C inheriting all properties 
of C. 

Technically the subclass would be seen as “concatenated” class in which the 
parameter parts, the block heads, and the block tails of the two classes were 
juxtaposed (The block tail of the prefixing class could be separated into initial 
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actions and final actions, that of the prefixed class sandwiched between them.) 
The attributes of a compound object would be accessible by dot notation down 
to the prefix level of the qualifying class of the reference used. Access to deeper 
levels could be achieved by class discrimination as in Simula I. 

The breakthrough happened in January of 1967. An IFIP sponsored working 
conference on simulation languages had been approved to take place in Oslo in 
May. There followed some hectic winter months during which our new concepts 
were explored and tested. A paper was ready just in time for advance distribution 
to the invitees, [7]. The new language was to be called Simula 67, [8]. The 
paper occurring in the proceedings was mended by the addition of “virtual” 
specifications, see below. 

One way of using a class, which appeared important to us, was to collect 
concepts in the form of classes, procedures, etc under a single hat. The resulting 
construct could be understood as a kind of “application language” defined on 
top of the basic one. It would typically be used as a prefix to an in-line block 
making up the application program. 

We illustrate this idea by showing a simplified version of a SIMULATION 
class defining the simulation oriented mechanisms used in our Simula I example. 

class SIMULATION] 
begin class process; 

begin real EventTime, NextEvent; end; 

ref(process) current; 

comment current points to the currently operating process. 

It is the head of the “time list” of scheduled ones, 
sorted with respect to nondecreasing EventTimes; 
real procedure time; time := cur rent. EventTime; 
procedure hold{deltaT); real deltaT; 
begin cur rent. EventTime := time+ deltaT; 

if time > current. NextEvent. EventTime then 

begin ref(process)P; P: — current; current : — P. NextEvent; 

<move P to the right position in the time list>; 
resume(current) end end of hold; 



end of SIMULATION; 



SIMULATION begin 
process class Car; 
begin real AO, TO, V; 

real procedure X; X := X0+V*{time—T0); 
procedure neivV (Vneiv) ; real Vnew; 

begin AO := A; TO := time; V := Vnew end; 

Car behaviour: ; /io/(i(<travel time>); 

end of Car; 
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process Police] 

begin ; inspect ^rocess> when Car do 

if X within city> and V^>50 then 

begin newV (50); <give fine> end; 

end of Police] 

main program: ^nitialise>; /ioW(<Bimulation period>) 
end of simulation model] 

Thus, the “block prefix” of Simula I is now an ordinary class declared within 
the new language, and the special purpose activity declarator is replaced by 
process class. 

We chose to introduce a special set of operators for references, in order to 
make it clear that the item in question is a reference, not (the contents of) the 
referenced object. The resume operator is a basic coroutine call, defined for the 
whole language. 

Notice that the class SIMULATION is completely self-contained. If some 
necessary initializing operations were added, it could be separately compiled 
and then used repeatedly in later programs. In actual fact a somewhat more 
elaborate class is predefined in Simula 67, providing an application language for 
simulation modelling. That class is itself prefixed by one containing mechanisms 
for the management of circular lists. 

It is fair to say that Simula 67 invites to bottom up program design, especially 
through the possibility of separate compilation of classes. As a last minute 
extension, however, we introduced a top down oriented mechanism through a 
concept of “virtual procedures” . 

In general attribute identifiers may be redeclared in subclasses, as is the case 
of inner blocks. The identity of an attribute is determined by the prefix level of 
the accessing occurrence, or, if the access is remote, by the class qualifying the 
object reference in question. In this way any ambiguity of identifier binding is 
resolved textually, i.e at compile time; we call it static binding. 

On the other hand, if a procedure P is specified as virtual in a class C 
the binding scheme is semi-dynamic. Any call for P occurring in C or in any 
subclass of C will bind to that declaration of P which occurs at the innermost 
prefix level of the actual object containing such a declaration (and similarly for 
remote accesses). Thus, the body of the procedure P may, at the prefix level of 
C, be postponed to occur in any subclass of C. It may even be replaced by more 
appropriate ones in further subclasses. 

This binding scheme is dynamic in the sense that it depends on the class 
membership of the actual object. But there is nevertheless a degree of compiler 
control; the access can be implemented as indirect through a table produced by 
the compiler for C and for each of its subclasses. 

As a concrete example the “fine giving” operation of the above example could 
be formalised as a virtual procedure, as follows: Redefine the head of the prefixed 
block as a subclass RoadTraffic of SIMULATION . In addition to the classes 
Car and Police declarations introduce the following specification: 

virtual procedure Fine{cr)] rei{Car)cr] 
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If appropriate the RoadTraffic class may be separately compiled. Using that 
class as a block prefix at some later time, a suitable fining procedure can be 
defined in that block head. 

There is an alternative more implementation oriented view of virtual pro- 
cedures. As mentioned in connection with Simula I, deletion of objects would 
have to be implicit (in Simula 67 by garbage collector alone) . But then there is a 
danger of flooding the memory with useless data, especially if there are implicit 
pointers between block instances. In Algol 60 there must be a pointer from a 
procedure activation back to its caller in order to implement procedure parame- 
ters and parameters “called by name” . Such pointers from objects back to their 
generating block instance would have been destructive. So, it was decided that 
parameters to objects must be called by “value” (including object references). 
The absence of procedure parameters, however, was felt to be a nuisance. For- 
tunately the virtual procedure mechanism provided a solution to the dilemma: 
a virtual procedure can be seen as a parameter, where the actual parameter 
is a procedure residing safely within the object itself, at an appropriate prefix 
level. There is the additional advantage that the procedure has direct access to 
attributes of the object containing it. 

Similar considerations led to forbidding class prefixing across block levels. 
Fortunately this would not prevent the use of separately compiled, “external” 
classes. Since there is no reference to nonlocal quantities in such a class, it can 
be called in as an external one at any block level of a user program. 

4 Language Finalisation and Distribution 

A couple of weeks after the IFIP Conference a private “Simula Common Base 
Conference” was organised, attended by several interested persons. The objective 
was to agree on the definition of a common core language. We made a proposal to 
the CBC to extend the language by “class-like” types giving rise to permanently 
named objects, directly accessed, thus extending the Algol variable concept. The 
proposal was prudently voted down, as not sufficiently worked through. However, 
a Pascal-like while statement was added, and the virtual mechanism was slightly 
revised. 

A “Simula Standards Group”, SSG, was established, to consist of represen- 
tatives from the NCC and various implementation groups. 5 compilers were 
implemented initially. It was decided that the NCC would propose mechanisms 
for text handling, I/O, and file handling. Our good colleague Bjprn Myhrhaug 
of the NCC gave three alternatives for text handling and I/O. The ones chosen 
by the SSG would have required class-like types in order to be definable within 
the Common Base. 

The class concept as it was formulated originally, was too permissive for 
the purpose of developing large systems. There was no means of enforcing a 
programming discipline protecting local class invariants (such as those expressed 
verbally for the Simulation class example). This was pointed out by Jacob Palme 
of the Swedish defence research institute. He proposed hiding mechanisms for 
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protecting variable attributes from unauthorised updating. The proposal was 
approved by the SSG as the last addition ever to the language. The authors toyed 
with the idea of class-like types for some time, but it was never implemented. 

The first compilers were operative already in 1969, three for Control Data 
computers. Then came implementations for UNIVAC and IBM machines. The 
general distribution of the compilers was, however, greatly hampered by the 
high prices asked for the compilers by the NCC, very unwisely enforced by the 
NTNF (Norwegian Council for Scientific and Technical Research) stating that 
programming languages only had a 3-5 years lifetime and thus had to provide 
profits within this time span. However, a nice compiler for the DEC 10 system, 
implemented by a Swedish team in the early 1970’s, contributed considerably 
to the spreading of the language. Lectures by OJD at NATO Summer Schools, 
as well as a chapter in [9] must have made the new concepts better known in 
academic circles. 

The most important new concept of Simula 67 is surely the idea of data 
structures with associated operators (and with or without own actions), called 
objects. There is an important difference, except in trivial cases, between 

— the inside view of an object, understood in terms of local variables, possibly 
initialising operations establishing an invariant, and implemented procedures 
operating on the variables maintaining the invariant, and 

— the outside view, as presented by the remotely accessible procedures, includ- 
ing some generating mechanism, dealing with more “abstract” entities. 

This difference, as indicated by the Car example in Simula I, and the 

associated comments, underlies much of our program designs from an early 
time on, although not usually conscious and certainly not explicitly formulated. 
(There is e.g an intended invariant of any Car object vaguely stating that its 
current position X is the right one in view of the past history of the object.) 

It was Tony Hoare who finally expressed mathematically the relationship of 
the two views in terms of an “abstraction function” , see [20] . He also expressed 
requirements for the concrete operations to correctly represent the corresponding 
abstract ones. Clearly, in order to enforce the use of abstract object views, read 
access to variable attributes would also have to be prevented. 

5 Cultural Impact 

The main impact of Simula 67 has turned out to be the very wide acceptance 
of many of its basic concepts: objects, but usually without own actions, classes, 
inheritance, and victuals, often the default or only way of binding “methods”, 
(as well as pointers and dynamic object generation). 

There is universal use of the term “object orientation”, 00. Although 
no standard definition exists, some or all of the above ideas enter into the 
00 paradigm of system development. There is a large flora of 00 languages 
around for programming and system specification. Conferences on the theory 
and practice of 00 are held regularly. The importance of the 00 paradigm 
today is such that one must assume something similar would have come about 
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also without the Simula effort. The fact remains, however, that the 00 principle 
was introduced in the mid 60’s through these languages. 

Simula 67 had an immediate success as a simulation language, and was, 
for instance extensively used in the design of VLSI chips, e.g. at INTEL. As a 
general programming language, its impact was enhanced by lectures at NATO 
Summer Schools given by OJD, materialized as a chapter in a book on structured 
programming, [9] . The latter has influenced research on the use of abstract data 
types, e.g., the CLU language, [29], as well as research on monitors and operating 
system design, [21]. 

A major new impact area opened with the introduction of workstations 
and personal computers. Alan Kay and his team at Xerox PARC developed 
Smalltalk, [15], an interactive language building upon Simula’s objects, classes 
and inheritance. It is oriented towards organising the cooperation between a user 
and her/his personal computer. 

An important step was the integration of 00 with a graphical user interfaces, 
leading the way to the Macintosh Operating System, and then to Windows. 

In the larger workstation field. Lisp was (and in some places still is) an 
important language, spawning dialects such as MACLISP, [16], at MIT, and 
InterLisp at Xerox PARC. Both got 00 facilities, MACLISP through ZetaLisp 
introducing also multiple inheritance, [2], and InterLisp through LOOPS (Lisp 
Object-Oriented Programming System). The object-oriented component of the 
merged effort, CommonLisp, is called CLOS (Common Lisp Object System), [24]. 

With the general acceptance of object-orientation, object-oriented databases 
started to appear in the 1980’s. The demand for software reuse also pushed 00 
tools, and in the 1990’s 00 tools for system design and development became 
dominant in that field. UML (Unified Modeling Language), [1], is very much 
used, and CORBA (Common Object Request Broker Architecture), is a widely 
accepted tool for interfacing 00 systems. The Microsoft Component Object 
Model, COM, [27], is an important common basis for programming languages 
such as Cj), as well as other tools. 

A large number of 00 programming languages have appeared. We list below 
some of the more interesting or better known languages, in addition to those 
mentioned above. 

— BETA is a compilable language built around a single abstraction mechanism, 
that of patterns, which can be specialised to classes, singular objects, types, 
as well as procedures. It was developed from the later 1970’s by KN and 
colleagues in Denmark, [25], [26]. 

— Bjarne Stroustrup extended the Unix-related language C with several 
Simula-inspired mechanisms. The language, called C-|— k, has been much used 
and has contributed importantly to the dissemination of the 00 ideas, [33]. 
Since C is fairly close to machine code, security aspects are not the best. As 
a result, complex systems may be difficult to implement correctly. C-k- 1- has 
been revised and extended, e.g. by multiple inheritance. 

— Eiffel, [28], is an 00 programming language designed by Bertrand Meyer in 
the 1980’s, well known and quite widely used. It has pre- and post-conditions 
and invariants. 
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— SELF, [34], is an 00 language exploring and using object cloning instead of 
object generation from a class declaration. 

— JAVA, [22], is a recent Simula-, Beta-, and C-|— I— inspired language, owing 
much of its popularity to its integration with the Internet. Its syntax is 
unfortunately rather close to that of C-I--I- and thus C (but with secure 
pointers). It contains Beta-like singular objects and nested classes, but not 
general block structure. Parallel, “multi-threaded”, execution is introduced, 
but outside compiler control. As a result, much of the programming security 
otherwise inherent in the language is lost. The synchronisation mechanisms 
invite to inefficient programming and do not facilitate good control of process 
sequencing, see [14]. 

The authors believed that the use of class declarations for the definition of 
“application languages” as natural extensions of a basic one would be of special 
importance in practice. However, although various kinds of packages or modules 
are defined for many languages, they are not consequences of a general class 
declaration as in Simula 67. 

The coroutine-like sequencing of Simula has not caught on as a general 
purpose programming tool. A natural development, however, would have been 
objects as concurrent processes, e.g. as in COM. 

One may fairly ask how it could happen that a team of two working in the 
periphery of Europe could hit on programming principles of lasting importance. 
No doubt a bit of good luck was involved. We were designing a language for 
simulation modelling, and such models are most easily conceived of in terms of 
cooperating objects. Our approach, however, was general enough to be applicable 
to many aspects of system development. 

KN oriented his activities for some years to trade union work, as well 
as system development and description, see [23]. In 1976 he turned back to 
programming language design, see BETA above. In [32] he introduced new 
constructs for 00 layered distributed systems. 

OJD has been professor of Informatics at Oslo University for the period 1968- 
1999, developing curricula including 00 programming. He has explored the 
concept of time sequences to reason about concurrent systems, [10], [11]. In [13] 
he applies techniques, such as Hoare logic and Guttag-Horning axiomatisation 
of types and subtypes, [31], to the specification and proof of programs, including 
00 ones. See also [12]. 

Of the Simula authors especially KN has been consistently promoting the 
00 paradigm for system development. 
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1 Introduction 

The development of Simula by Ole-Johan Dahl and Kristen Nygaard introduced 
a number of important programming language concepts - object which supports 
modularity in programming through encapsulation of data and procedures, the 
concept of class which organizes behavior and supports Abstract Data Types, 
and the concept inheritance which provides subtyping relations and reuse [6]. 
Peter Wegner terms programming languages which use objects as object-based 
languages, and reserves the term object-oriented languages for languages which 
also support classes and inheritance [58] . 

Concurrency provides a natural model for the execution of objects: in fact, 
Simula uses co-routines to simulate a simple form of concurrency in a sequen- 
tial execution environment. The resulting execution is tightly synchronized and, 
while this execution model is appropriate for simulations which use a global 
virtual clock, it is not an adequate model for distributed systems. The Actor 
Model unifies the notion of objects with concurrency; an actor is a concurrent 
object which operates asynchronously and interacts with other actors by sending 
asynchronous messages [2]. 

Many models for concurrent and distributed computation have been devel- 
oped. An early and influential model is Petri Nets developed by Carl Adam Petri 
[44]. In the Petri Net model, there are two kinds of elements - nodes and tokens. 
Nodes are connected to other nodes by fixed (static) links. Tokens are passed be- 
tween nodes using these links. The behavior of each node is governed by reactive 
rules which are triggered based on the presence of tokens at the nodes. 

Another popular model of concurrency is based on communicating processes. 
Two exponents of this sort of model are Robin Milner who defined the Calculus 
of Communicating Systems (CCS) [38], and Tony Hoare who defined the pro- 
gramming language. Communicating Sequential Processes (CSP) [20]. In both 
these systems, asynchronous processes have a fixed communication topology 
(processes which can communicate with each other are statically determined) 
and the communication is synchronous - i.e. a message exchange involves an 
explicit handshake between the sender and the receiver. 

In contrast to these models, the notion of actors is very flexible. In the earliest 
formulation of the Actor Model, an actor was defined by Carl Hewitt as an 
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autonomous agent which has intentions, resources, contain message monitors 
and a scheduler [19]. Later work by Hewitt and his associates developed a more 
abstract model of parallelism based on causal relations between asynchronous 
events at different actors - where an event represents the sending or receiving of 
a message [10, 16]. The formulation of the Actor Model that most people refer 
to is based on the transition system in Agha [1]. In particular, this formulation 
provides a basis for the operational semantics developed in [3]. 

The Actor Model is more flexible than Petri Nets, CCS or CSP. Petri Nets 
have been generalized to Colored Petri Nets which allow tokens to carry data. It is 
possible to encode actor computations in this more general model by interpreting 
actor behaviors although it is not clear how useful such an encoding is [42]. 

In fact, the work on actors inspired Robin Milner to develop the 7r-calculus 
[41], a model which is more general than CCS. As Milner reports: “. . . the pure A- 
calculus is built with just two kinds of things: terms and variables. Can we achieve 
the same economy for a process calculus? Carl Hewitt, with his Actor Model, 
responded to this challenge a long ago; he declared that a value, an operator on 
values, and a process should all be the same kind of thing: an actor. This goal 
impressed me, because it implies a homogeneity and completeness of expression 
.... But it was long before I could see how to attain the goal in terms of an 
algebraic calculus .... So, in the spirit of Hewitt, our first step is to demand that 
all things denoted by terms or accessed by names-values, registers, operators, 
processes, objects-are all the same kind of thing; they should all be processes. 
Thereafter we regard access-by-name as the raw material of computation . . . .” 
[39]. 

The TT-calculus allows names to be communicable - thus capturing an essen- 
tial aspect of actors which provides it greater flexibility. However, there are num- 
ber of differences between the two models that are caused by differing goals and 
ontological commitments. The goal of explicitly modeling distributed systems 
has motivated the development of actors, while the goal of providing an alge- 
braic formulation has been central to work on 7r-calculus. As a consequence, the 
Actor Model uses asynchronous communication which is natural in distributed 
systems, while the 7r-calculus uses synchronous communication which results in 
a simpler algebra. As in object-based systems, each actor has a distinct identity 
which is bound to a unique name which does not change. By contrast, in the 
TT-calculus, different processes can have the same name, and these names can 
disappear. 

This paper develops a formal calculus for actors by imposing suitable type 
restrictions on the 7r-calculus. Our aim is to gain a better understanding of the 
implications of the different ontological commitments of the Actor Model. We 
present a typed variant of 7r-calculus, called Att, which is an accurate representa- 
tion of the Actor Model, and we investigate a basic theory of process equivalence 
in Att. We then illustrate how Att can be used to provide formal semantics for 
actor-based concurrent programming languages. The Actor Model has served 
as the basis of a number of object-based languages [4, 59]. Since our aim is to 
investigate the effects of only the basic ontological commitments of the Actor 
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Model, we focus our presentation on a simple actor-based language which was 
first defined in [1]. 

Following is the layout of the rest of this paper. In Section 2, we give a brief 
and informal description of the Actor Model, and in Section 3, we describe a 
simple actor language (SAL). In Section 4, we present the calculus Att, and in 
Section 5, we investigate a basic theory of process equivalence in Att. In Section 
6, we provide a formal semantics for SAL by translating its programs to Att. 
In Section 7, we conclude the paper with an overview of several other research 
directions that have been pursued on the basic Actor Model over the last two 
decades. 

2 The Actor Model 

A computational system in the Actor Model, called a configuration, consists of a 
collection of concurrently executing actors and a collection of messages in transit 
[1]. Each actor has a unique name (the uniqueness property) and a behavior, and 
communicates with other actors via asynchronous messages. Actors are reactive 
in nature, i.e. they execute only in response to messages received. An actor’s 
behavior is deterministic in that its response to a message is uniquely determined 
by the message contents. Message delivery in the Actor Model is fair [10]. The 
delivery of a message can only be delayed for a finite but unbounded amount of 
time. 

An actor can perform three basic actions on receiving a message (see Fig- 
ure 1): (a) create a finite number of actors with universally fresh names, (b) send 
a finite number of messages, and (c) assume a new behavior. Furthermore, all 
actions performed on receiving a message are concurrent; there is no ordering 
between any two of them. The following observations are in order here. First, 
actors are persistent in that they do not disappear after processing a message 
(the persistence property). Second, actors cannot be created with well known 
names or names received in a message (the freshness property). 

The description of a configuration also defines an interface between the con- 
figuration and its environment, which constrains interactions between the two. 
An interface is a set of names p, called the receptionist set, that contains names 
of all the actors in the configuration that are visible to the environment. The 
only way an environment can effect the actors in a configuration is by sending 
messages to the receptionists of the configuration; the non-receptionist actors 
are all hidden from the environment. Note that uniqueness of actor names au- 
tomatically prevents the environment from receiving messages in configuration 
that are targeted to the receptionists, because to receive such messages the en- 
vironment should have an actor with the same name as that of a receptionist. 
The receptionist set may evolve during interactions, as the messages that the 
configuration sends to the environment may contain names of actors are not 
currently in the receptionist set. 
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Fig. 1. A diagram illustrating computation in an actor system. 



3 A Simple Actor Language (SAL) 

A SAL program consists of a sequence of behavior definitions followed by a single 
(top level) command. 



Pgm ::= BDefi ... BDef^ Com 

The behavior definitions are templates for actor behaviors. The top level com- 
mand creates an initial collection of actors and messages, and specifies the in- 
terface of the configuration to its environment. 

3.1 Expressions 

Three types of primitive values - booleans, integers and names - are presumed. 
There are literals for boolean and integer constants, but none for names. Primi- 
tive operations include A, V, ^ on booleans, -I-, — , *, = on integers. Expressions 
always evaluate to values of one of the primitive types. An expression may con- 
tain identifiers which may be bound by formal parameters of the behavior def- 
inition in which the expression occurs (see behavior definitions in Section 3.3). 
Identifiers are lexically scoped in SAL. We let e range over the syntactic domain 
of expressions, and u,v,w,x,y, z over actor names. 
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3.2 Commands 

Following is the syntax for SAL commands. 



Com ::= send [ei, e„] to x 
become B{e\, e„) 
let x\ = [recep] new 
. . . Xk = [recep] new Bk{ei, 
in Com 

if e then Comi else Com 2 
case X of [yi : Comi , . . . ,yn 
Comi II Com2 



■5 


(message send) 
(new behavior) 


■) 


(actor creations) 
(conditional) 


Com„) 


(name matching) 
(composition) 



Message send: Expressions ei to e„ are evaluated, and a message containing 
the resulting tuple of values is sent to actor x. A message send is asynchronous: 
execution of the command does not involve actual delivery of the message. 

New behavior: This specifies a new behavior for the actor which is executing 
the command. The identifier B should be bound by a behavior definition (see 
behavior definitions in Section 3.3). Expressions e\ to e„ are evaluated and the 
results are bound to the parameters in the acquaintance list of B. The resulting 
closure is the new behavior of the actor. A become command cannot occur in 
the top level command of an actor program, because the top level command 
specifies the initial system configuration and not the behavior of a single actor. 

Actor creations: Actors with the specified behaviors are created. The identifiers 
xi, . . . , x„, which are all required to be distinct, denote names of the actors, and 
the command Com is executed under the scope of these identifiers. In the top 
level command of a program, the identifiers can be optionally tagged with the 
qualifier recep. The corresponding actors will be receptionists of the program 
configuration, and can thus receive messages from the environment; all the other 
actors are (at least initially) private to the configuration. The set of receptionists 
can of course expand during the execution, as messages containing the names of 
non-receptionists are sent to the environment. 

While the scope of the identifiers declared as receptionists is the entire top 
level command, the scope of the others is only the let command. Because actor 
names are unique, a name can not be declared as a receptionist more than once 
in the entire top level command. An actor creates new actors with universally 
fresh names, and these names must be communicated before they can be used 
by any actor other than the creator. This freshness property would be violated if 
any of the new actors is declared as a receptionist. Therefore, the recep qualifier 
can not be used in behavior definitions. 

Conditional: The expression e should evaluate to a boolean. If the result is true, 
command Com\ is executed, else Com 2 is executed. 
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Name matching: The name x is matched against the names yi, ... ,y„. If there is 
a match, the command corresponding to one of the matches is non-deterministic- 
ally chosen and executed. If there is no match, then there is no further execution 
of the command. Note that the mismatch capability on names is not available, 
i.e. it is not possible to take an action based on the failure of a match. 

Composition: The two composed commands are executed concurrently. 

A couple of observations are in order here. First, there is no notion of sequen- 
tial composition of commands. This is because all the actions an actor performs 
on receiving a message, other than the evaluation order dependencies imposed 
by the semantics, are concurrent. Second, message passing in SAL is analogous 
to call-by-value parameter passing; expressions in a send command are first eval- 
uated and a message is created with the resulting values. Alternately, we can 
think of a call-by-need message passing scheme. But both the mechanisms are 
semantically equivalent because expressions do not involve recursions and hence 
their evaluations always terminate. 

3.3 Behavior Definitions 

The syntax of behavior definitions is as follows. 

BDef ::= def {beh name) {{acquaintence list))[{input list)] 

Com 

end def 

The identifier {beh name) is bound to an abstraction and the scope of this 
binding is the entire program. The identifiers in acquaintance list are formal pa- 
rameters of this abstraction, and their scope is the body Com. These parameters 
are bound during a behavior instantiation, and the resulting closure is an actor 
behavior. The identifiers in input list are formal parameters of this behavior, 
and their scope is the body Com. They are bound at the receipt of a message. 
The acquaintance and input lists contain all the free identifiers in Com. The 
reserved identifier self can be used in Com as a reference to the actor which 
has (an instance of) the behavior being defined. The execution of Com should 
always result in the execution of at most a single become command, else the be- 
havior definition is said to be erroneous. This property is guaranteed statically 
by requiring that in any concurrent composition of commands, at most one of 
the commands contains a become. If the execution of Com does not result in 
the execution of a become, then the corresponding actor is assumed to take on 
a ‘smfc’ behavior that simply ignores all the messages it receives. 

3.4 An Example 

SAL is not equipped with high-level control flow structures such as recursion 
and iteration. However, such structures can be encoded as patterns of message 
passing [18]. The following implementation of the factorial function (adapted 
from [1]) shows how recursion can be encoded. The example also illustrates 
continuation passing style of programming common in actor systems. 
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Fig. 2. A diagram illustrating computation of factorial 3, whose result is to be 
sent back to the actor c. The vertical lines denote time lines of actors. An arrow 
to the top of a time line denotes an actor creation. Other arrows denote messages. 



def Factorial {)[val,cust] 

become Factorial () || 
if val = 0 

then send [1] to cast 

else let cont = new FactorialCont (val,cust) 
in send [val — 1, cont] to self 

end def 

def FactorialCont {val,cust)[arg] 
send [val * arg] to cust 

end def 

A request to factorial actor includes a positive integer n and the actor name 
cust to which the result has to be sent. On receiving a message the actor creates 
a continuation actor ccmt and sends itself a message with contents n — 1 and 
cont. The continuation actor has n and cust as its acquaintances. Eventually a 
chain of continuation actors will be created each knowing the name of the next 
in the chain (see Figure 2). On receiving a message with an integer, the behavior 
of each continuation actor is to multiply the integer with the one it remembers 
and send the reply to its customer. The program can be proved correct by a 
simple induction on n. Note that since the factorial actor is stateless, it can 
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process different factorial requests concurrently, without affecting the result of 
a factorial evaluation. 

Following is a top level command that creates a factorial actor that is also a 
receptionist and sends a message with value 5 to it. 

let X = [recep] new FactorialQ 

in send [5] to x 

4 The Calculus Att 

The Actor Model and 7r-calculus have served as the basis of a large body of 
research on concurrency. In this section, we represent the Actor Model as a typed 
asynchronous 7r-calculus [7, 21], called Att. The type system imposes a certain 
discipline on the use of names to capture actor properties such as uniqueness, 
freshness and persistence. This embedding of the Actor Model in 7r-calculus not 
only provides a direct basis for comparison between the two models, but also 
enables us to apply concepts and techniques developed for 7r-calculus to the 
Actor Model. As an illustration of how the theory of behavioral equivalences 
for TT-calculus can be adapted to the Actor Model, we develop a theory of may 
testing for Att in Section 5. In the interest of space and simplicity, we skip the 
proofs of all the propositions we state. In fact, the proofs are variations of the 
ones presented in [53, 54]. 



4.1 Syntax 

We assume an infinite set of names Af, and let u, v, w, x,y, z, . . . range over Af. 
The set of configurations, ranged over by P, Q, R, is defined by the following 
grammar. 



P := 0 1 x{y).P 1 xy \ {vx)P \ P 1 IP 2 

1 case X of (j/i : Pi, . . . ,y„ : P„) ] B{x;y) 

The order of precedence among the constructs is the order in which they are 
listed. The reader may note that, as in the 7r-calculus, only names are assumed 
to be primitive in Att. As we will see in Section 6, datatypes such as booleans 
and integers, and operations on them, can be encoded as Att processes. These 
encodings are similar to those for 7r-calculus [40]; the differences arise mainly 
due to the typing constraints imposed by Att. 

Following is the intended interpretation of Att terms as actor configurations. 
The nil term 0, represents an empty configuration. The output term xy, repre- 
sents a configuration with a single message targeted to x and with contents y. We 
call X the subject of the output term. Note that unlike in SAL, where tuples of 
arbitrary length can be communicated, only a single name can be communicated 
per message in Att. As we will explain in Section 4.3, polyadic communication 
(communication of tuples of arbitrary length) can be encoded in Att, although 
only after relaxing the persistence property. The input term x{y).P represents 
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Fig. 3. A visualization of the Att term R = {i/x){x{u).Pi\y{v).Qi\xy\zy) \ 
{vx){x{u).P 2 \z{v).Q 2 \wx). a box around subterms indicates a restriction op- 
erator. An outlet next to an actor inside the box indicates that the actor is a 
receptionist for the configuration. 



a configuration with an actor x whose behavior is {y)P- The parameter y con- 
stitutes the formal parameter list of the behavior {y)P, and binds all the free 
occurrences of y in P. The actor x can receive an arbitrary name z and substi- 
tute it for y in the definition of P, and then behave like P{z/y} (see below for 
the definition of substitution). We call x the subject of the input term. 

The restricted process {vx)P is the same as P, except that x is no longer a 
receptionist of P. All free occurrence of x in P are bound by the restriction. Thus, 
the receptionists of a configuration P, are simply those actors whose names are 
not bound by a restriction. The composition P\\P 2 is a configuration containing 
all the actors and messages in Pi and P 2 - The configuration case x of (t/i : 
Pi, . . . ,y„ : P„) behaves like Pi if x = yi, and like 0 if x yf for 1 < f < n. 
If more than one branch is true, one of them is non-deterministically chosen. 
Note that this construct does not provide mismatch capability on names, i.e. it 
does not allow us to take an action based on the failure of a match. Thus, this 
construct is much like the case construct of SAL. 

The term B{u;v) is a behavior instantiation. The identifier B has a single 

dsf 

defining equation of the form B = (x; y)xi{z).P, where x is a tuple of distinct 
names of length 1 or 2, and xi denotes the first component of x. This definition, 
like a behavior definition in SAL, provides a template for an actor behavior. 
The tuples x and y together contain exactly the free names in xi{z).P, and 
constitute the acquaintance list of the behavior definition. The reason behind 
the constraint on length of x will be clear in Section 4.2. For an instantiation 
B{u;v), we assume len{u) = len{x), and len{v) = len{y). In the case where v is 
the empty tuple, we write B{u) as a shorthand for B{u;). 

For example, the configuration 

R= {vx){x{u).Pi\y{v).Qi\xy\zy) \ {vx){x{u).P 2 \z{v).Q 2 \wx) 

is a composition of two sub-configurations (see Figure 3). The first consists of 
two actors x and y, a message targeted to x, and a message targeted to an actor 
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z that is external to the sub-configuration. The actor j/ is a receptionist, while x 
is hidden. The second sub-configuration, also contains two actors x and z, and 
a message targeted to an external actor w. Note that although the name x is 
used to denote two different actors, the uniqueness property of actor names is 
not violated in R because the scopes of the two restrictions of x do not intersect. 
The actors y and z are receptionists of the configuration R. 

The reader may note that we use the case construct and recursive defini- 
tions instead of the standard match {[x = y]P) and replication (!P) operators 
of TT-calculus. We have chosen these constructs mainly because they are more 
convenient in expressing actor systems. However, both these constructs can be 
encoded using the match and replication operators. For instance, the reader can 
find an encoding of recursive definitions using the standard 7r-calculus constructs 
in [40]. 

Before presenting the type system, a few notational conventions are in order. 
For a tuple i, we denote the set of names occurring in x by {i}. We denote the 
result of appending y to i by i, y. We assume the variable z ranges over {0, {z}}. 
By X, z we mean x,z ii z = {z}, and x otherwise. By (i>z)P we mean (i'z)P if 
z = {z}, and P otherwise. We define the functions for free names, bound names 
and names, /n(.), bn{.) and n(.), of a process as expected. As usual, we do not 
distinguish between alpha-equivalent processes, i.e. between processes that differ 
only in the use of bound names. A name substitution is a function on names that 
is almost always the identity. We write {y/x} to denote a substitution that maps 
Xi to yi and is identity on all other names, and let a range over substitutions. We 
denote the result of simultaneous substitution of yi for Xi in P by P{y/x}. As 
usual, we define substitution on processes only modulo alpha-equivalence, with 
the usual renaming of bound names to avoid captures. 

4.2 Type System 

Not all terms represent actor configurations. For example, the term 
x{u).P\x{v).Q violates the uniqueness property of actor names, as it contains 
two actors with name x. The term x{u) .{u{v) .P\x{v) .Q) violates the freshness 
property because it creates an actor with name u that is received in a message. 
Uniqueness of actor names and freshness of names of newly created actors, cap- 
ture essential aspects of object identity. We enforce such constraints by imposing 
a type system. 

Enforcing all actor properties directly in Att results in a language that is 
too weak to express certain communication patterns. For example, consider ex- 
pressing polyadic communication in Att, where tuples of arbitrary length can be 
communicated. Since communication in Att is monadic, both the sending and 
receiving actors have to exchange each component of the tuple one at a time, and 
delay the processing of other messages until all the arguments are transfered. 
But on the other hand, the persistence property implies that both the actors are 
always ready to process any message targeted to them. We therefore relax the 
persistence requirement, so that instead of assuming a new behavior immedi- 
ately after receiving a message, an actor can wait until certain synchronization 
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conditions are met before processing the next message. Specifically, we allow an 
actor to assume a series of fresh names, one at a time, and resume the old name 
at a later point. Basically, the synchronization task is delegated from one new 
name to another until the last one releases the actor after the synchronization 
conditions are met. 

We assume _L, * ^ Af, and for X C Af define X* = X\J {_L, *}. For f : X ^ 
X* , we define f* : X* X* as f*{x) = f{x) for x G X and /*(-L) = /*(*) = _L. 
A typing judgment is of the form p; f \- P, where p is the receptionist set of P, 
and f : p p* is a, temporary name mapping function that relates actors in P 
to the temporary names they have currently assumes. Specifically 

— f{x) = _L means that x is a regular actor name and not a temporary one, 

— f{x) = * means x is the temporary name of an actor with a private name 
(bound by a restriction), and 

— f{x) = y ^ {-L, *} means that actor y has assumed the temporary name x. 
The function / has the following properties. For all x,y G p, 

— f{x) yf x: This holds for obvious reasons. 

— f{x) = f{y) ^ {-L,*} implies x = y: This holds because an actor cannot 
assume more than one temporary name at the same time. 

— /*(/(x)) = T: This holds because temporary names are not like regular 
actor names in that they themselves cannot temporarily assume new names, 
but can only delegate their capability of releasing the original actor to new 
names. 



We define a few functions and relations on the temporary name mapping func- 
tions, that will be useful in defining the type rules. 



Definition 1. Let fi'.pi^ p* and f2 ■ P 2 ^ P 2 - 



1. We define /i 0 /2 : Pi U p 2 ^ {pi U P 2 )* as 



ifl 0 f 2 ){x) 



fi{x) if X G Pi, and fi{x) yf T or x ^ p2 
f 2 (x) otherwise 



Note that 0 is associative. 

2. If p C Pi we define f\p : p ^ p* as 



(f\p)M = l* if fix) G Pi -p 
\J\P)\ f(x) otherwise 

3. We say fi and /2 are eompatihle if f = /i 0 /2 has following properties: 
/ = /2 0 fi, and for all x,y G pi U p 2 , f{x) yf x, /*(/(x)) = T, and 
fix) = fiy) i {-L, *} implies x = y. □ 



Definition 2. For a tuple x, we define c/i(x) : {x} ^ {5}* as c/i(e) = {}, and 
if lenix) = n, c/i(x)(xj) = Xj+i for 1 < i < n and c/i(x)(x„) = T. □ 
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NIL: 0; {} h 0 



ACT: 






MSG: 0; {} h xy 
p-{x} =z, yip, and 



{x}VJ z-,ch(x,z)\- x{y).P f = 



ch(x, z) if X £ p 



CASE. 



ch(e, z) otherwise 
VI < i < n pi’,fi\- Pi 



(UiPi); (/i © /2 © • ■ • © /n) b case a: of (j/i : Pi, . . . , : P„) 

if fi are mutually compatible 

Pi;/lbPl P2', f2 P 2 . ^ 

LUMP: n I — „ I „ if pinp 2 = <p 



RES: 



pi U P 2 ; /i © /2 b P 1 IP 2 
p;/bP 



P- {*};/l(p- {a:}) b [vx)P 
INST: {x}; ch{x) b B{x',y) if len{x) = 2 implies xi 7 ^ X 2 



Table 1. Type rules for Att. 



The type rules are shown in Table 1. Rules NIL and MSG are obvious. In 
the ACT rule, if z = {z} then actor z has assumed temporary name x. The 
condition yip ensures that actors are not created with names received in a 
message. This is what is commonly referred to as the locality property in the tt- 
calculus literature [35] The conditions yip and p— {x} = z together guarantee 
the freshness property by ensuring that new actors are created with fresh names. 
Note that it is possible for x to be a regular name, i.e. p— {x} = 0, and disappear 
after receiving some message, i.e. x i p. We interpret this as the actor x having 
assumed a sink behavior, i.e. that it simply consumes all the messages that it 
now receives. With this interpretation the intended persistence property is not 
violated. Note that a similar interpretation was adopted to account for the case 
where the body of a SAL behavior definition does not execute a become command 
(see Section 3.3). 

The compatibility check in CASE rule prevents errors such as: two actors, 
each in a different branch, assuming the same temporary name; or, the same 
actor assumes different temporary names in different branches. The COMP rule 
guarantees the uniqueness property by ensuring that the two composed con- 
figurations do not contain actors with the same name. In the RES rule, / is 
updated so that if x has assumed a temporary name y in P, then y’s role as a 
temporary name is remembered but x is forgotten. The INST rule states that 
if len{x) = 2, then B{x;y) denotes a configuration containing a single actor X 2 
that has assumed temporary name xi. 



^ In the context of 7 r-calculus, the locality constraint stipnlates that a processes can 
not receive a name and listen to it; the constraint is enforced by the simple syntactic 
rnle that in a term x(y).P, the name y can not occur as the subject of an input. 
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Type checking a term involves checking the accompanying behavior defi- 

dsf 

nitions. For INST rule to be sound, for every definition B = {x]y)xi{z).P 
and substitution a = {u,v/x,y} that is one-to-one on {i}, the judgment 
{■u}; ch{u) h {xi{z).P)a should be derivable. From Lemma 1, it follows that 
this constraint is satisfied if {i}; ch{x) h x\{z).P is derivable. Thus, a term is 

dcf 

well-typed only if for each accompanying behavior definition B = (i; y)x\ (z) .P, 
the judgment {i}; ch{x) h xi{z).P is derivable. 

The following theorem states a soundness property of the type system. 

Theorem 1. If p', f F P then p C fn{P), and for all x,y G p, f{x) yf x, 
f*{f{x)) = _L, and f{x) = f{y) ^ {_L, *} implies x = y. Furthermore, if p'; f F 
P then p = p' and f = f ■ □ 

Not all substitutions on a term P yield terms. A substitution a may identify 
distinct actor names in P, and therefore violate the uniqueness property. But, if 
cr renames different actors in P to different names, then Pa will be well typed. 
This is formally stated in Lemma 1, where we have used the following notation. 
For a set of names X, a{X) denotes the set obtained by applying the substitution 
a to each element of X. Further, if ct is a substitution which is one-to-one on 
X, fa : a{X) <x{X)* is defined as fa{a{x)) = a{f{x)), where cr(-L) = _L and 
cr(*) = *. 

Lemma 1. If p; f \- P and a is one-to-one on p then a{p)] fa F Pa. □ 

A consequence of Lemma 1 is that the type system respects alpha-equivalence, 
i.e. if P\ and P 2 are alpha-equivalent, then p; / F Pi if and only if p; / F P 2 . For 
a well-typed term P, we define rcp{P) = p if p; / F P for some /. 

4.3 Operational Semantics 

We specify the operational semantics of Att using a labeled transition system 
(see Table 2). The rules are obtained by simple modifications to the usual rules 
for asynchronous 7r-calculus [7]. The modifications simply account for the use 
of case construct and recursive definitions instead of the standard match and 
replication operators. 

The transition system is defined modulo alpha-equivalence on processes, i.e. 
alpha-equivalent processes are declared to the same transitions. The symmetric 
versions of COM, CLOSE, and PAR, where the roles of Pi and P 2 are inter- 
changed, are not shown. Transition labels, which are also called actions, can be 
of five forms: r (a silent action), xy (free output of a message with target x and 
content y), x{y) (bound output), xy (free input of a message), and x{y) (bound 
input). We denote the set of all visible (non-r) actions by C, let a range over C, 
and let (3 range over all the actions. 

The interpretation of these rules in terms of the Actor Model, is as follows. 
The INP rule represents the receipt of a message by an actor, and the OUT 
rule represents the emission of a message. The BINP rule is used to infer bound 
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INP x{y).P P{z/y} 
OUT xy^O 



p JUU p' 

BINP p._^p, Vi HP) 



RES- 



jVi n(a) 



{vy)P — > {vy)P‘ 



PAR _ bn{a) n fn{P2) = I 



P1IP2 Pl'|P 2 

CLOSE. 



p —U p' 

OPEN ^ x^y 

(^y)P-^P' 

Pi ^Pj P2APU P' 

P1IP2 ^ P1IP2 



COM 



p ^{y) p/ p xy p/ 



P1IP2 ^ {yy){Pi\P2) 

BRNCH case a; of (j/i : Pi, . . . ,y„ : Pn) — ^ Pi if x = yi 
{xi{z).p){{u,v) /{x,y)} ^ P' de_f ^ 



BEHV- 



B{u-,v) ^ P' 



■ B = {x;y)xi{z).P 



Table 2. A labeled transition system for Att. 



inputs, i.e. receipt of messages that contain actor names that were previously 
unknown to the receiving configuration. The RES rule states that an action a 
performed by P can also be performed by {vx)P, provided x does not occur in a. 
This condition disallows the emission of a message which contains the name of 
a hidden actor in the configuration (a non-receptionist), and prevents confusing 
a received name with the name of a hidden actor. The OPEN rule accounts for 
the former type of actions, while the latter can be accounted for by an alpha- 
conversion of the recepient {vx)P to a term {vy)P{y / x}, where y does not occur 
in a, and then applying the RES rule. Note that in the OPEN rule, the hidden 
actor name that is being emitted is bound in the output action, but is no longer 
bound by a restriction in the transition target. Thus, the actor which was hidden 
in the transition source, becomes a receptionist in the target. The side condition 
of the OPEN rule prevents the emission of messages that are targeted to the 
hidden actor. 

The PAR rule captures the concurrent composition of configurations. The 
side condition of the rule prevents erroneous inferences of bound inputs and 
outputs. For example, if Pi performs a bound input x{y), and y G fn{P2), then 
the entire configuration P1IP2 can not perform the bound input x{y) as it already 
‘knows’ the name y. Similarly, it would be erroneous to allow bound outputs of 
Pi with the output argument occuring free in P2; such behavior would confuse 
the name of a previously hidden actor with the name of another actor. 

The COM rule is used to infer the communication of a receptionist name 
between two composed configurations. The CLOSE rule is used to infer the 
communication of non-receptionist names between the configurations. The side 
condition prevents confusion of the private name that is communicated, with 
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other names in the recipient P 2 - Note that the transition target has a top-level 
restriction of the communicated name; thus the actor whose name is communi- 
cated (internally) is still a non-receptionist in the transition target. 

The BRNCH and BEHV rules are self explanatory. The following theorem 
states that the type system respects the transition rules. 

Theorem 2. If P is well-typed and P P' then P' is well-typed. 

Since well- typed terms are closed under transitions, it follows that actor prop- 
erties are preserved during a computation. However, note that the source and 
the target of a transition need not have the same typing judgment. Specifically, 
both the receptionist set and the function that relates actors to the temporary 
names they have assumed, may change. For instance the receptionist set changes 
when the name of a hidden actor is emitted to the environment, or an actor dis- 
appears after receiving a message. (The reader may recall that the latter case 
is interpreted as the actor assuming a sink behavior.) Similarly, the temporary 
name map function changes when an actor with a temporary name re-assumes 
its original name. 

Example 1 (polyadic communication). We show how the ability to temporarily 
assume a fresh name can be used to encode polyadic communication in Att. 
Suppose that the subject of a polyadic receive is not a temporary name. In 
particular, in the encoding below, x cannot be a temporary name. The idea 
behind translation is to let x temporarily assume a fresh name 2 : which is used 
to receive all the arguments without any interference from other messages, and 
re-assume x after the receipt. For fresh u, z we have 

\x{yi, . . . ,yn)\ = {vu){xu\ Si{u-,yi,...,yn)) 

Si = {u-,yi, . . . ,yn)u{z).{zyi \ Si+i{u]yi+i, 

Sn (u;yn)u{z).zyn 

[x{yi,...,yn).P] = x{u).{i^z){uz \ Ri{z,x;u,a)) 
dcf 

Ri = {z,x]u,d)z{yi).{uz \ Ri+i{z,X]u,d)) 

Rn (z,x;u,d)z(yn).(uz | |P]) 

where a = fn{x{y\, . . . ,yn)-P) — {x}, and x = {x} if for some p,f, we have 
pU{x};/h|P], and X = 0 otherwise. □ 

Before we proceed any further, a few definitions and notational conventions 
are in order. The functions /n(.), bn{.) and n(.) are defined on C as expected. As 
a uniform notation for free and bound actions we adopt the following convention 
from [7]: (0)xj/ = xy, {{y})xy = x{y), and similarly for input actions. We define 
a complementation function on C as {y)xy = {y)xy, {y)xy = {y)xy. The vari- 
ables s,r,t are assumed to range over L* . The functions /n(.), hn{.), n(.), and 
complementation on C are extended to C* the obvious way. Elements in C* are 



...,yn)) l<i<n 



1 < i < n 
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called traces. Alpha-equivalence over traces is defined as expected, and alpha- 
equivalent traces are not distinguished. The relation denotes the refiexive 

transitive closure of — and denotes =^-^=^. For s = 1. s' , P ^ ^ > Q 

is compactly written as P Q, and similarly P Q as P = 4 > Q. The 

assertion, P P' for some P', is written as P and similarly P and 
P 

Not every trace produced by the transition system corresponds to an actor 
computation. For instance, we have 

{i^x){x{u) .P\xx\yx) x{u).P\xx 

But the message xx is not observable; due to the uniqueness property of actor 
names, there can never be an actor named x in the environment. To account for 
this, we define for any set of names p, the notion of a p-well-formed trace such 
that only p-well-formed traces can be exhibited by an actor configuration with 
p as its initial receptionist set. 

Definition 3. For a set of names p and trace s we define rcp{p,s) inductively 
as 

rcp(p, e)= p rcp{p, s.{y)xy) = rcp{p, s) rcp{p, s.{y)xy) = rcp{p, s)Uy 

We say s is p-well-formed if s = si.{y)xy.S2 implies x ^ rcp{p,si). We say s is 
well-formed if it is %-well-formed. □ 

The following lemma captures our intuition. 

Lemma 2. Let P\Q he a well-typed Att term with rcp{P) = p\ and rcp{Q) = p2- 

Then P\Q can he unzipped into P and Q such that s is pi-well- 

formed ands is p2-well-formed. □ 

For convenience, since we work only modulo alpha-equivalence on traces, we 
adopt the following hygiene condition. Whenever we are interested in p-well- 
formed traces, we will only consider traces s such that if s = si.a.S2, then 
{p U n(si) U fn{a)) n hn{a.S2) = 0 . 

The transition sequences are further constrained by a fairness requirement 
which requires messages to be eventually delivered, if they can be. For example, 
the following transition sequences are unfair. 

Diver ge{x)\xu\y{v).vv\yv — ^ Diver ge{x)\xu\y{v).vv\yv 

— ^ Diver ge{x)\xu\y{v).vv\yv 

T 

where Diverge = {x)x{u).{xu \ Diverge{x)) 

In every transition above, the message xy is delivered to its target; but the 
message yv is never delivered. 
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Fairness in actors requires that the delivery of a message is not delayed in- 
finitely long; but it can be delayed for any finite number of steps. Thus, only 
infinite transition sequences can be unfair. However, note that our fairness con- 
straint does not require that every message is eventually delivered to its target. 
Because we have relaxed the persistence property, an actor may disappear during 
a computation, after which all the message targeted to it become permanently 
disabled. Thus, the fairness criteria only requires that there is no message that is 
infinitely often enabled, but not delivered. This is consistent with our convention 
that an actor that disappears is assumed to take on a sink behavior. 

The fairness requirement can be enforced by defining a predicate on sequences 
of transitions as described in [48] such that only fair sequences satisfy the pred- 
icate. However, we do not pursue this any further in this paper, as fairness does 
not effect the theory we are concerned with. The reader is referred to Section 5.4 
for further discussion. 



4.4 Discussion 

There has been considerable research on actor semantics in the past two decades. 
We set Att in the context of some of the salient work. A significant fraction of 
the research has been in formal semantics for high level concurrent programming 
languages based on the Actor Model, e.g. [3, 13] where a core functional language 
is extended with actor coordination primitives. The main aim of these works has 
been to design concurrent languages that could be useful in practice. Accordingly, 
the languages assume high-level computational notions as primitives, and are 
embellished with type systems that guarantee useful properties in object-based 
settings. In contrast, Att is a basic calculus that makes only the ontological 
commitments inherent in the Actor Model, thus giving us a simpler framework 
for further theoretical investigations. In Section 6, we show how Att can be used 
to give a translational semantics for SAL. 

In [48, 49] , actors are modeled in rewriting logic which is often considered as a 
universal model of concurrency [33, 36]. An actor system is modeled as a specific 
rewrite theory, and established techniques are used to derive the semantics of 
the specification and prove its properties. In a larger context, this effort belongs 
to a collection of works that have demonstrated that rewriting logic provides 
a good basis to unify many different concurrency theories. For example, we 
have also a rewrite theory formulation of the 7r-calculus [52]. In comparison, 
Att establishes a connection between two models of concurrency that is deeper 
than is immediately available from representing the two models in a unified basis. 
Specifically, the theory that we have developed in Section 5, can be seen as a more 
elaborate investigation of the relationship between two specific rewrite theories, 
and provides a formal connection that helps in adapting and transferring results 
in one theory to the other. 

There are several calculi that are inspired by the Actor Model and the tt- 
calculus [15, 22, 45]. But these are neither entirely faithful to the Actor Model, 
nor directly comparable to the 7r-calculus. For example, they are either equipped 
with primitives intrinsic to neither of the models [15, 22], or they ignore actor 




An Algebraic Theory of Actors 



43 



properties such as uniqueness and persistence [45]. These works are primarily 
intended for investigation of object-oriented concepts. 

5 A Theory of May Testing for Att 

Central to any process calculus is the notion of behavioral equivalence which is 
concerned with the question of when two processes are equal. Typically, a notion 
of success is defined, and two processes are considered equivalent if they have 
the same success properties in all contexts. Depending on the chosen notion of 
context and success one gets a variety of equivalences [8, 12, 46]. 

The may testing equivalence is one such instance [17, 12], where the con- 
text consists of an observing process that runs in parallel and interacts with the 
process being tested, and success is defined as the observer signaling a special 
event. The possible non-determinism in execution leads to at least two possibil- 
ities for the definition of equivalence. In may testing, a process is said to pass 
a test proposed by an observer, if there exists at least one run that leads to 
a success. By viewing a success as something bad happening, may testing can 
be used for reasoning about safety properties. An alternate definition, where a 
process is said to pass a test if every run leads to a success, is called the must 
testing equivalence. By viewing a success as something good happening, must 
testing can be used for reasoning about liveness properties. In this paper, we 
will be develop only with the theory may testing for Att. 

Context-based behavioral equalities like may testing suffer from the need for 
universal quantification over all possible contexts; such quantification makes it 
very hard to prove equalities directly from the definition. One solution is to find 
an alternate characterization of the equivalence which involves only the processes 
being compared. We provide an alternate characterization of may testing in 
Att that is trace based and directly builds on the known characterization for 
asynchronous 7r-calculus. 



5.1 A Generalized May Preorder 

As in any typed calculus, may testing in Att takes typing into account; an ob- 
server O can be used to test a configuration P only if P\0 is well- typed. Note 
that P\0 is well-typed only if rcp{P) C rcp{0) = 0. Thus, O can be used to test 
the equivalence between P and Q only if rcp(O) C {rcp{P) U rcp{Q)) = 0. 

The uniqueness property of actor names naturally leads to a generalized 
version of may testing, where the equivalence is tagged with a parameter p. 
All possible observers O that do not listen on names in p, i.e. rcp{0) n p = 0, 
are used for deciding ~p. Of course, for processes P and Q to be compared with 
~p, it has to be the case that rcp{P) , rcp{Q) C p. 

Definition 4 (may testing). Observers are processes that can emit a special 
message JIp. We let O range over the set of observers. We say O accepts a 

trace s if O =^. For P,0, we say P may O if P\0 =^. For p such that 
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(LI) 


si-{y)s 2 


A 


si.{y)xy.S2 


if {y)s 2 7 ^ A 


(L2) 


si.{y){a.xy.S2) 


A 


si.{y)xy.a.S2 


if {y){a.xy.S2) 7^ A 


(L3) 


si-{y)s 2 


A 


si.{y)xy.xy.S2 


if {y)s 2 7^ A 


(L4) 


si.xw.{s2{w/y}) 


A 


si.x{y).S2 





Table 3. A preorder relation on traces. 



rcp{P),rcp{Q) C p, we say P Q, if for every O such that rcp{0) n p = 0, 
P may O implies Q may O. We say P ~p Q if P Q and Q P. □ 

The relation ~p is a preorder, i.e. reflexive and transitive, and ~p is an 
equivalence relation. Further, note that the larger the parameter p, the smaller 
the observer set that is used to decide ~p. Hence if pi C p 2 , we have P ~pj Q 
implies P ^p^ Q. However, P ^p^ Q need not imply P ~pj Q. For instance, 
0 — {x} XX, but only 0 ^0 xx and xx^^ 0. Similarly, xx —{x,y} Vv, but xx -^0 yy 
and yy'^0 xx. However, P Sp^ Q implies P ~pj Q if fn{P) U fn{Q) C p\. 

Theorem 3. Let p\ C p2- Then P £pj Q implies P ~p 2 Q. Furthermore, if 
fn{P) \J fn{Q) C Pi then P ~p 2 Q implies P ~pj Q. □ 

5.2 An Alternate Characterization of May Testing 

We now build on the trace-based characterization of may testing for asyn- 
chronous TT-calculus presented in [7] to obtain a characterization of may testing 
in Att. Following is a summary of the alternate characterization of may testing 
in asynchronous 7 r-calculus. To account for asynchrony, the trace semantics is 
modified using a trace preorder A that is defined as the reflexive transitive clo- 
sure of the laws shown in Table 3, where the notation {y)- is extended to traces 
as follows. 



{ s if D = 0 or y ^ /^(s) 

si.x{y).S2 if D = {j/} and there are si, S 2 , x s.t. 

s = s\.xy.S2 and y ^ fn{si) U {x} 

A otherwise 

The expression {y)s returns A, if y = {j/} and y is used in s before it is received 
for the first time, i.e. the first free occurrence of j/ in s is not as the argument 
of an input. Otherwise, the expression returns the trace s with the first such 
free input changed to a bound input. The (unparameterized) may preorder ~ 
in asynchronous 7r-calculus (which corresponds to ~0 in our setting) is then 
characterized as: P ^ Q if and only if P implies Q =A for some r A s. 

The intuition behind the preorder is that if an observer accepts a trace s, 
then it also accepts any trace r A s. Laws L1-L3 capture asynchrony, and L4 
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captures the inability to mismatch names. Laws LI and L2 state that an observer 
cannot force inputs on the process being tested. Since outputs are asynchronous, 
the actions following an output in a trace exhibited by an observer need not be 
causally dependent on the output. Hence the observer’s outputs can be delayed 
until a causally dependent action (L2), or dropped if there are no such actions 
(LI). Law L3 states that an observer can consume its own outputs unless there 
are subsequent actions that depend on the output. Law L4 states that without 
mismatch an observer cannot discriminate bound names from free names, and 
hence can receive any name in place of a bound name. The intuition behind 
the trace preorder is formalized in the following lemma that is proved in [7] for 
asynchronous 7r-calculus. 

Lemma 3. If P then r P s implies P =^. □ 

We note that, the lemma above also holds for Att with very simple modifications 
to the proof. 

Actor properties such as uniqueness and freshness “weaken” may equivalence 
in Att, in comparison to asynchronous 7r-calculus. Specifically, the type system of 
Att reduces the number of observers that can be used to test actor configurations. 
For example, the following two processes are distinguishable in asynchronous tt- 
calculus, but equivalent in Att: 

P = {vx){x{z) .Q\xx\yx) Q = {vx){x{z) .Q\yx) 

The observer O = y{z) .z{w) .jLy. can distinguish P and Q in asynchronous tt- 
calculus, but is not a valid Att term as it violates the freshness property {ACT 
rule of Table 1). In fact, no Att term can distinguish P and Q, because the 
message xx is not observable. 

The following alternate preorder on configurations characterizes the may pre- 
order in Att. 

Definition 5. We say P <Sip Q, if for every p-well-formed trace s, P im- 
plies there is r ^ s such that Q =^. □ 

To prove the characterization, we define an observer 0{s) for a well-formed 
trace s, such that P may 0(s) implies P for some r P s. 

Definition 6 (canonical observer). For a well-formed trace s, we define an 
observer 

0(s) = (i^x, z)(jy^^^Proxy(s, yi, z) | 0'(s,z)), where z fresh 

{i} = set of names occurring as argument of hound input actions in s 
X = set of names occuring as subject of output actions in s 

0'(e,z) = fly 

O' {{v)uv.s, z) = uvjO'(s, z) 
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0'{uv.s, z) = z{wi,W 2 )-ca.se wi of {u : case W 2 of {v : 0'{s, z))) Wi,W 2 fresh 
0'{u{v).s, z) = z{w,v). case w of {u : 0'(s,z)) w fresh 



Proxy {e, y,z) = 0 



A 



Proxy {{v)uv.s, y, z) = Proxy{s, y, z) 

Pro„j{{v)u„.s,,,z) = 



Proxy{s,y, z)) w fresh 



if u = y 
otherwise 



In the above, = is used for macro definitions. The reader may verify that \ ~ 
{x}; f h 0{s) where f maps every name in its domain to _L. Further, if s is 
p-well-formed we have rcp{0{s)) C\ p = %, because the set of names occurring as 
subject of output actions in a p-well-formed trace is disjoint from p. □ 



The observer 0(s) consists of a collection of proxies and a central matcher. 
There is one forwarding proxy for each external name that a configuration sends 
a message to while exhibiting s. The proxies forward messages to the matcher 
which analyzes the contents. This forwarding mechanism (which is not nec- 
essary for the construction of canonical observers in the corresponding proof 
for asynchronous 7 r-calculus), is essential for Att because of uniqueness of actor 
names. Further, note that the forwarding mechanism uses polyadic communica- 
tion, whose encoding was shown in Section 4.3. The following lemma formalizes 
our intention behind the construction of 0 (s). 



Lemma 4. For a well- formed trace s, 0(s) implies r < s. □ 

The following theorem, which establishes the alternate characterization of 
may preorder in Att, can be proved easily using Lemmas 2, 3, and 4. 

Theorem 4. P ^pQ if and only if P <Cp Q. □ 



5.3 Some Axioms for May Testing 

Table 4 lists some inference rules besides the reflexivity and transitivity rules, 
and some axioms for £p. For an index set I = {1, . . . ,n}, we use the macro 
Pi to denote, {vu){case u of {u \ P\, . . . ,u \ Pn)) for u fresh if / yf 0, and 
0 otherwise. For an index set that is a singleton, we omit / and simply write ^ P 
instead of variable G range over processes of form Xie/ 

We write Xie/ Pi + ^jej Pj denote Xfce/aj Pk- We write C as a shorthand 
for [l 0 , and = for =0 . 

Axioms A1 to A 17 are self explanatory. We note that they also hold in 
asynchronous 7 r-calculus [7]. But axiom A18 is unique to Att. It captures the fact 
that a message targeted to an internal actor in a configuration, cannot escape to 
the environment. The axiom states that there are only two ways such a message 
can be handled in the next transition step: it can be consumed internally or de- 
layed for later. The axiom also allows for dropping of the message permanently, 
which is useful when the message target no longer exists (it may have disappeared 
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11 

12 
13 
U 

A1 

A2 

A6 

A7 

A8 

A9 

AID 

All 

A12 

A13 

A14 

A15 

A16 

A17 

A18 



A P \—p Q and rcp{R) H p = 0, then {vx)P ^p-{x} {i^x)Q, P\R Qp Q\R. 
if for each « G fn{P,Q) P{z/y} Cp Q{z/y} then x(y).P Cp x{y).Q 
if for each i G / Pi Cp Qij then Yi<=i J2iei,jeJ '5b 

if pi C P 2 and P Cp^ Q then P Cpj Q. 



G + G^G A3 P\0 = P A5 {P\Q)\R = P\{Q\R) 

GQG + G' A4 P\Q = Q\P 



{iyx){P\Q) = P\{iyx)Q 
{i’x){xy\a.P) — a.{izx){xy\P) 
{ux){xy\x{z).P) = {iyx){P{y/z}) 



X ^ n(P) 
X ^ n(a) 



®ylEie/-R = Eie/(®yl^0 
p = YP 



x{y).{uv\P) ^ uv\x{y).P y^u,yj^v 

P{y/z} E xy\x{z).P 

x{y).{xy\P) CP y^ n{P) 



{vx)P C P{y/x} 



li X € p, w ^ X and w ^ y, then 

xy\z{w).P Cp X] z{w).{xy\P) + X) z{w).P + YQ 



where Q 



_ J P{v/'^} A X = z 

I 0 otherwise 



Table 4. Inference rules and axioms for ~p in Att. 



during the computation) . As an application of this axiom, if x G p, we can prove 
xy Ep 0 as follows. For iv fresh, 



xy Gp xyj(iyw)(w(w).0) (A3,A10,I1) 

Ep (b'u;)(xj/|t(;(tc).0) 

Ep (b'u;)(X)ic(w)-0 + X]''i'(w')-^J/ + Z]0) \a18,I1) 

Ep Yi^'X’){w{w).0)+Yi^''x>)w{w)-xy + ^{vw)0 {A6) 

Ep 0 \a1,A10,A13,I3) 



Inference rules II and 13 are self explanatory, while 14 is motivated by The- 
orem 3. We illustrate II through some examples. First, using xy E{a;} 0 (proved 
above) and II, we get {vx)xy E (bx)0, and by axiom All we have (h'x)O E 0. 
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Therefore, {vx)xy C 0. Note the use of the ability to contract the parameter p 
of the may preorder after applying a restriction. Second, the following example 
illustrates the necessity of the side condition rcp{R) n p = 0 for composition: 
'^y ~{x} 0 but not xy\x{y) .yy ~{a,} x{y).yy, for the LHS can satisfy the observer 
y{u).JIp and the RHS can not. 

Note that the inference rules are generalizations of rules for asynchronous tt- 
calculus presented in [7], in order to handle parameterization of the may preorder. 
In fact, the rules for asynchronous 7r-calculus can be obtained by setting p = 0 
in II, 12 and IS. Rule IJ^ is unique to the parameterized may preorder. 

The soundness of rules Il-IJ^ can be easily proved directly from Definition 4. 
Soundness of the axioms is easy to check. For A1-A17, whenever P C Q, we have 
P =^, implies Q such that r P s. For A18 , both LHS and RHS exhibit the 
same p- well- formed traces. The reader can verify that A18 would also be sound 
as an equality. 

5.4 Discussion 

The alternate characterization of may testing for Att turns out to be the same 
as that for Ltt^ which we presented in [54]. L7 t= is a version of asynchronous 
TT-calculus with match operator and the locality constraint (see Section 4.2 for 
a discussion on locality). This shows that of all the constraints enforced by the 
type system of Att, only locality and uniqueness (which is taken care of by 
parameterization of the may preorder) has an effect on may testing. 

In Section, 4.3, we claimed that the fairness property of the Actor Model does 
not affect the theory we have presented. The justification is simple. May testing 
is concerned only with the occurrence of an event after a finite computation, 
while fairness affects only infinite computations. An interesting consequence of 
fairness, however, is that must equivalence [17] implies may equivalence, which 
was shown for a specific actor-based language in [3] . It can be shown by a similar 
argument that this result holds in Att also. 

There has been a significant amount of research on notions of equivalence and 
semantic models for actors, including asynchronous bisimulation [15], testing 
equivalences [3], event diagrams [10], and interaction paths [50]. We have not 
only related may testing [3] to the interaction paths model [50], but also related 
our characterizations to that of asynchronous 7r-calculus and its variants. 



6 Formal Semantics of SAL 

Att can serve as the basis for actor based concurrent programming languages. 
As an illustration, we give a formal semantics for SAL by translating its pro- 
grams into Att. The translation can be exploited to apply the characterizations 
established in Section 5 to reason about programs in SAL. 

In Sections 6.1 and 6.2, we show how booleans, natural numbers and oper- 
ations on them can be represented as processes in Att. These data types, along 
with names, are assumed as primitive in SAL. Of course, this exercise is not 
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entirely necessary, and in fact, a better strategy may be to directly consider an 
extended version of Att with basic data types. The characterizations for Att can 
be adapted in a straightforward manner to the extended calculus. We have cho- 
sen the other approach here, mainly to illustrate that the type system of Att does 
not reduce the expressive power of the calculus. In Sections 6. 3-6. 5, we present 
the translation of SAL expressions, commands and behavior definitions. SAL 
expressions and commands are translated into Att terms, and their evaluation is 
modeled as computation in these terms. SAL behavior definitions are translated 
into recursive definitions in Att. 



6.1 Booleans 

Booleans are encoded as configurations with a single actor that is also a recep- 
tionist. In the following, T defines the receptionist behavior for true, and F for 
false. 

T {x)x{u,v,c).cu 
£ {x)x{u,v,c).cv 

The behaviors accept messages containing three names, of which the last name 
is assumed to be the customer name (see Section 4.3 for an encoding of polyadic 
communication). The behavior T replies back to the customer with the first 
name, while £ replies back with the second name. 

The negation function can be encoded as follows 

d&f 

Not = {x)x{u, c).{vv, y, z){u{y, z, v) \ v{w).caLse w oi{y : F_{v), z : 21{v))) 

Not{x) can be thought of as the function not available at name x. Evaluation of 
the function is initiated by sending a message containing a value and a customer 
name, to x. The customer eventually receives the negation of the value sent. The 
reader may verify that 



Not{x) I F_{u) I x{u,c) T{v) 

Following is the encoding of boolean and 
d&f 

And = {x)x{u,v,c).{vy,zi,Z2){u{zi,Z2,y) \ v{zi,Z2,y) \ 

y{wi).y{w 2 ).{cy \ 

case wi of ( 

2 : 1 : case W 2 of (zi : T(y),Z 2 : F{y)), 
Z 2 - F{y) ))) 

The reader may verify the following 

And{x) I T_{u) I F_{v) \ x{u, v, c) ^{y) 



The reader may also verify that for each behavior B defined above {x}; {x 
T} h B{x). 
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6.2 Natural Numbers 

Natural numbers are built from the constructors 0 and S. Accordingly, we define 
the following two behaviors. 

Zero'^= {x)x{u,v,c).c{u,x) 

Succ'^= {x,y)x{u,v,c).c{v,y) 

With these, natural numbers can be encoded as follows. 

0(x) = Zero{x) 

A"+^0 (a;) = {vy){Succ{x,y) \ S^{y)) 

The number S'"0 is encoded as a sequence of n + 1 actors each pointing to the 
next, and the last one pointing to itself. The first n actors have the behavior 
Succ and the last has behavior Zero. Only the first actor is the receptionist to 
the entire configuration. As in our encoding for booleans, both the behaviors 
accept messages with three names, the last of which is assumed to denote the 
customer. The behavior Succ replies back to the customer with the second name 
and the name of next actor in the sequence, while Zero replies back with the 
first name and its own name. 

We only show the encoding of the addition operation, and hope the reader is 
convinced that it is possible to encode the others. Our aim is to define a behavior 
Add such that 

Add{x) I ^(u) I CT(u) I x{u,v,c) ^ 

We first define a behavior AddT o such that 

AddTo{x) I (i^u)( S'^0 (u) \ x{u,v,c)) \ S"^0 (v) (iyu)( S^^"^0 (u) \ cu) 

We will then use AddTo to define Add. 

AddTo = {x)x{ui,U 2 ,c).{vyi,y 2 ,w){u^{yi,y 2 ,w) \ 

w{zi,Z 2 ).ca.se z\ of ( 

yi ■ cui, 

7/2 : {vv){Succ{v,ui) I x{v,Z 2 ,c) I AddTo{x)))) 
We are now ready to define Add. 

Add = {x)x{u,v,c).{izy, z,w){AddTo{y) \ 0 ( 77 ;) | y{w,u,z) \ 

z{w).{vy){AddTo{y) \ y{w,v,c))) 

Lemma 5. Add{x) \ S^O (u) \ S^O (v) \ x{u,v,c) 5 ’"~*~’"0 f7c') 

The reader may verify that for a natural number N, and each behavior B 
defined above, {x}; {x T} h N_{x), and {x}; {x T} h B{x). This encoding 
of natural numbers can be extended to integers in a fairly straightforward manner 
(for example, by using tags to indicate the sign). 
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6.3 Expressions 

Now that we have a representation of the basic constituents of expressions - 
namely, booleans, integers, and names - what remains is the representation of 
dependencies between the evaluation of subexpressions of an expression. 

The translation of an expression takes as an argument, the name of a cus- 
tomer to which the result of the expression’s evaluation is to be sent. An identifier 
expression x is translated as 

\x\c = cx 

A constant (boolean or integer) expression e is translated as 

|e]c= {vy){e{y) \ cy) 

where e is the encoding of the constant e. For an n— ary operator Op, the ex- 
pression Op{ei, ..., e„) is encoded as 

\Op{ei, . . . ,e„)]c = {lyyi,.. . ,yn+i, z){Marshal{yi, . . ,,yn+i,z) \ 

\ei]yi I ... I |e„]j/„ | | Opjz)) 

where Op is the encoding of operator Op, and z, yt are fresh. The expressions 
ei to e„ are concurrently evaluated. The configuration Marshal{y \, . . . , yn+i, z) 
marshals their results and the customer name into a single tuple, and forwards it 
to an internal actor that implements Op. The marshaling configuration is defined 
as 



Marshal{yi, . . . ,yn,c) = {iyu){R{yi,u) | ... | R{yn,u) \ S'i(m, j/i, . . . , j/„, c)) 
where 

R (x,y) x{u)Jj{u,x) 

c def . s 

'u;).case w of { 

Vi ■ (x, yi-\-l yn-) ^ 

yi+i...yn ■■ Si{x,yi, . . . ,y„,vi, . . . ,Vi-i,c) \ x{vi,w)) 

for 1 < f < n 

Sn {x,Vi, . . .,Vn-l,c) x{Vn , w) ,c{vi , . . . , V„) 

By structural induction on an expression e and name x, it is easy to show 
that 0; {} h \e\x. 



6.4 Commands 

Although the Actor Model stipulates that the actions an actor performs on re- 
ceiving a message are all concurrent, execution of SAL commands may involve 
sequentiality. For example, expressions need to be evaluated before the results 
are used to send messages or instantiate a behavior. This sequentiality is rep- 
resented as communication patterns in the Att configurations that encode these 
commands. The translation of a command takes as an argument, the name of 
the SAL actor which executes the command. In the following, we assume that 
the names introduced during the translation are all fresh. 
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Message send: We use the Marshal configuration to marshal the results of ex- 
pression evaluations into a polyadic message to the target. 

[send [ei,...,e„] to z]x = {iryi, . . . ,yn){Marshal{yi, . . . ,yn, z) \ 

\ei]yi I ... I |e„]y„) 

New behavior: We use an actor’s ability to temporarily assume a new name to 
wait for the results of expression evaluations before assuming the new behavior. 

[become B{ei, e„)|a; = {vyi , . . . , z){\ei\yi | . . . | [e„|2/„ | 

Marshal {y I , ...,yn,z) \ 

Z(ui, Un).B(x, Ml, ... , M„)) 

where B is the Att behavior definition that is the translation of the SAL behavior 
definition B (see Section 6 . 5 ). 

Actor creation: The identifiers in the let command are used as names for the 
new actors. If not tagged by the recep qualifier, these names are bound by a 
restriction. The actors are created at the beginning of command execution, but 
they assume a temporary name until their behavior is determined. 

[let j/i = [recep] new . . . , eq), 

... yk= [recep] new Bk{ei , . . . , CjJ in Com\x = 

(i/y)(|become Bi(ei, . . . ,eij]i/i I ... | 

[become Bk{ci, ei^)\yk \ \Com]x) 

where y consists of all yi which have not been qualified with recep. 

Conditional: We use a temporary actor that waits for the outcome of the test 
before executing the appropriate command. 

[if e then Comi else Com2\x = 

{vu){\e\u I u{z).{vvi,V2){z{vi,V2,u) I 

u{w). ca.se w of (mi : [Com]x,V2 '■ [Com]x)) 

Name matching: The translation simply uses the case construct of Att. 

[case z of(yi : Comi , . . . ,yn : C'om„)[a; = 

case z of (yi : [Comi ]x, . . . ,y„ ■ [C'om„[x) 

Concurrent Composition: The translation of a concurrent composition is just 
the composition of individual translations. 

[Comi II Com2]x = [Comi[a; | [Com2]x 

This completes the translation of commands. Let Com be a command such 
that in any of its subcommands that is a concurrent composition, at most one 
of the composed commands contains a become. Further, assume that a name is 
declared as a receptionist at most once, and that let constructs with receptionist 
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declarations are not nested under other let or conditional constructs. Let x be a 
fresh name. Then by structural induction on Com, we can show that {x, y}; f h 
[Com\x if Com contains a become, and {y}', f b \Com\x otherwise, where y is 
the set of all names declared as receptionists in Com, and / is a function that 
maps all names in its domain to _L. 

6.5 Behavior Definitions 

Behavior definitions in SAL are translated to behavior definitions in Att as fol- 
lows 



[def Com end def] = {self -, 11 ) self {v)\Com\self 

Note that the implicitly available reference self in a SAL behavior definition 
becomes explicit in the acquaintance list after translation. Since the body of 
a behavior definition does not contain receptionist declarations, it follows that 
{self}; {self _L} h self (v) .\Com]self . So the RHS is well-typed. 

We have completed the translation of various syntactic domains in SAL, and 
are ready to present the overall translation of a SAL program. Recall that a 
SAL program consists of a sequence of behavior definitions and a single top level 
command. Following is the translation. 

[BDef^ ... BDef.^ Com\ = \BDef^\ ... \BDef [Com]x 

where x is fresh. Since the top level command cannot contain a become, its 
translation does not use the argument x supplied. Indeed, {y}; f b [Com]x, 
where {y} is the set of all names declared as receptionists in Com, and / maps 
all names in {y} to _L. 

6.6 Discussion 

The translation we have given, can in principle be exploited to use the testing 
theory developed for Att, to reason about SAL programs. Note that the char- 
acterization of may-testing for Att applies unchanged to SAL. This is because 
the set of experiments possible in SAL have the same distinguishing power as 
the experiments in Att. Specifically, the canonical observers constructed for Att 
in Section 5, are also expressible in SAL. Further, it follows immediately from 
Lemma 4 and Theorem 4 that these observers have all the distinguishing power, 
i.e. are sufficient to decide ~p in Att. 

Although, SAL is a very simple language, it can be enriched with higher level 
programming constructs without altering the characterization. This is corrobo- 
rated by the work in [34], where a high level actor language is translated to a 
more basic kernel language (similar to SAL) in such a way that the source and 
its translation exhibit the same set of traces. 

Translational semantics for actor languages similar to SAL has been previ- 
ously attempted. In [II] a simple actor language is translated into linear logic 
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formulae, and computations are modeled as deductions in the logic. In [29] an 
actor-based object-oriented language is translated into HACL extended with 
records [28]. These translations provide a firm foundation for further semantic 
investigations. However, to reap the benefits of these translations, one still has 
to explicitly characterize actor properties such as locality and uniqueness in the 
underlying formal system, and identify the changes to the theory due to them. 
For instance, the asynchronous 7r-calculus can be seen as the underlying sys- 
tem of our translation, whereas only Att terms correspond to SAL programs, 
and the characterization of may testing for Att is very different from that for 
asynchronous 7r-calculus. 



7 Research Directions 

In this paper, we have focused only on the semantic aspects of the Actor Model, 
while much of the actor research over the last two decades has been on languages 
and systems. 

Actor programming has been effective in combining benefits of object style 
encapsulation with the concurrency of real-world systems. The autonomy of ac- 
tors frees a programmer from the burden of explicitly managing threads and syn- 
chronizing them. In fact, the autonomy of actors also facilitates mobility. Over 
the years, many implementations of the Actor Model have been done [9, 55, 59]. 
In fact, the numerous agent languages currently being developed typically fol- 
low the Actor Model [32, 23]. The Actor Model has also been used for efficient 
parallel computation [24, 26, 27, 51]. Actor languages and systems currently be- 
ing developed include SALSA for web computing [56] , Ptolemy II for embedded 
systems [30] , and ActorFoundry for distributed computing [43] . 

An important area of active research in the Actor Model is the use of compu- 
tational reflection [31]. The execution environment of an actor application can 
be represented as a collection of actors called meta-actors. These meta-actors 
constitute the middleware which mediates the interaction of the actor applica- 
tion and the underlying operating systems and networks. In order to customize 
fault-tolerance, security, synchronization and other types of interaction proper- 
ties, meta-actors may be customized (see, for example, [5, 47]). Moreover, the 
meta-actor model supports the ability to express dynamic coordination policies 
as executable synchronization constraints between actors: the constraints may be 
enforced by customizing the meta-actors during execution [14]. An operational 
semantics of such reflective systems is developed in [57] and a rewriting model 
has been proposed in [37]. 

The use of meta-actors supports a separation of design concerns which is 
now popularly known as aspect- oriented programming [25]. The development of 
aspect-oriented programming will enable the reuse of interaction protocols and 
functional behavior of an object. The separation of the concurrent interaction 
protocols from the sequential behavior of actors is another step in the revolution 
in programming that was instigated by Dahl and Nygaard when they developed 
the idea of separating the interface of an object from its representation. 
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Abstract. Some facts: Before software and computing systems can be 
developed, their requirements must be reasonably well understood. Be- 
fore requirements can be finalised the application domain, as it is, must 
be fairly well understood. Some opinions: In today’s software and com- 
puting systems development very little, if anything is done, we claim, to 
establish fair understandings of the domain. It simply does not suffice, we 
further claim, to record assumptions about the domain when recording 
requirements. Far more radical theories of application domains must be 
at hand before requirements development is even attempted. In another 
(“earlier”) paper [6] we advocate(d) a strong role for domain engineering. 
We there argued that domain descriptions are far more stable than are 
requirements prescriptions for support of one or another set of domain 
activities. In the present paper we shall argue, that once, given extensive 
domain descriptions, it is comparatively faster to establish trustworthy 
and stable requirements than it is today. And we shall further, presently, 
argue that once we have a sufficient (varietal) collection of domain spe- 
cific, ie. related, albeit distinct, requirements, we can develop far more 
reusable software components than using current approaches. In this con- 
tribution we shall thus reason, at a meta-level, about two major phases of 
software engineering: Requirements engineering, and software design. We 
shall suggest a number of requirements engineering and software design 
concerns, stages and steps 

The paper represents work in progress. It is based on presentations of 
“topics for discussion” at the IFIP Working Group 2.3. Such presenta- 
tions are necessarily of “work in progress” — with the aim of the pre- 
sentation being to solicit comments. Hence the paper (“necessarily”) is 
not presenting “final” results. 
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1 Introduction 

Our concern, in the present and in most of our work in the last almost 30 years, 
has been that of trying to come to grips with principles and techniques for 
software development. 

The present paper sketches some such principles and techniques for some of 
the stages within the phases of requirements engineering and software design. 

Our lecture notes, [7], the reader will find a rather comprehensive treatment 
of these and “most other related” software engineering issues ! 



1.1 Itemised Summary 

Some facts: 

— Before software and computing systems can be developed, their requirements 
must be reasonably well understood. 

— Before requirements can be finalised the application domain, as it is, must 
be fairly well understood. 

Some opinions: 

— In today’s software and computing systems development very little, if any- 
thing is done, we claim, to establish fair understandings of the domain. 

— It simply does not suffice, we further claim, to record assumptions about the 
domain when recording requirements. 

— Far more radical theories of application domains must be at hand before 
requirements development is even attempted. 

In another (“earlier”) paper [6] we advocate(d) a strong role for domain engi- 
neering. 

— We there argued that domain descriptions are far more stable than are re- 
quirements prescriptions for support of one or another set of domain activi- 
ties. 

— In the present paper we shall argue, that once, given extensive domain de- 
scriptions, it is comparatively faster to establish trustworthy and stable re- 
quirements than it is today. 

— And we shall further, presently, argue that once we have a sufficient (vari- 
etal) collection of domain specific, ie. related, albeit distinct, requirements, 
we can develop far more reusable software components than using current 
approaches. 

In this contribution we shall thus reason, at a meta-level, about two major phases 
of software engineering: 

— Requirements engineering, and 

— software design. 
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We shall suggest a number of requirements engineering and software design 
concerns, stages and steps, notably, for 

— requirements: 

• Domain requirements, 

• interface requirements, and 

• machine requirements. 

— Specifically: 

• Domain requirements projection, 

• determination, 

• extension, and 

• initialisation. 

— And Software Design: 

• Architecture design, and 

• component determination and design. 

1.2 Claimed, ‘Preliminary’ Contributions 

We claim that this paper reports on two kinds of methodological contributions: 
The “posit & prove calculation” principles of projection, determination, exten- 
sion and initialisation; and the principle of the stepwise “posit & prove calcula- 
tion” of software architecture design. 

2 Requirements Engineering 

2.1 Delineation of Requirements 

From [23] we quote: “Requirements engineering must address the contextual 
goals why a software is needed, the functionalities the software has to accom- 
plish to achieve those goals, and the constraints restricting how the software 
accomplishing those functions is to be designed and implemented. Such goals, 
functions and constraints have to be mapped to precise specifications of software 
behaviour; their evolution over time and across software families has to be coped 
with as well [29].” 

We shall, in this paper, not cover the pragmatics of why software is needed, 
and we shall, in this paper, exclude “the mapping to precise software specifica- 
tions” as we believe this is a task of the first stages of software design — as will 
be illustrated in this paper. 

2.2 Requirements Acquisition 

The process of requirements acquisition will also not be dealt with here. We 
assume that proper such techniques, if available, will be used. For example [16, 
8, 18, 9, 15, 28, 20, 14, 10, 17, 25, 24, 26, 19, 27]. That is: We assume that somehow 
or other we have some, however roughly, but consistently expressed itemised set 
of requirements. We admit, readily, that to achieve this is a major feat. The 
domain requirements techniques soon to be outlined in this paper may help 
“parameterise” the referenced requirements acquisition techniques. 




Towards Posit & Prove Calculi 



61 



2.3 On the Availability of Domain Models 

It is a thesis of this paper that it makes only very little sense to embark on 
requirements engineering before one has a fair bit of understanding of the appli- 
cation domain. Granted that one may feel compelled to develop both “simulta- 
neously”, or that one ought expect that others have developed the domain de- 
scriptions (including formal theories) “long time beforehand.” Yes, indeed, just 
as control engineers can rely on Newton’s laws and more than three hundred 
years of creating improved understanding of the domain of Newtonian physics: 
The “mechanical” world as we see it daily, so software engineers ought be able, 
sooner or later, to rely on elsewhere developed models of — usually man-made 
— application domains. Since that is not yet the situation we shall in software 
engineering have to make the first attempts at creating such domain-wide de- 
scriptions — hoping that eventually the domain specific professions will have 
reseachers with sufficient computing science education to hone and further de- 
velop such models. 

2.4 Domain Requirements 

It is also a thesis of this paper that a major, perhaps the most important aspects 
of requirements be systematically developed on the basis of domain descrip- 
tions. This ‘thesis’ thus undercuts much of current requirements engineerings’ 
paradigms, it seems. 

By a domain requirements we shall understand those requirements (for a 
computing system) which are expressed solely by using terms of the application 
domain (in addition to ordinary language terms). Thus a domain requirements 
must not contain terms that designate the machine, the computing system, the 
hardware -I- software to be de viced. 

How do we go about doing this ? 

There seems to be two orthogonal approaches. In one we follow the domain 
facets outlined above. In the other we apply a number of “operators”, to wit: 

— projection, determination, extension, and initialisation, 
to domain required facets. We treat the latter first: 

Facet-Neutral Domain Requirements: 

— Projections: 

Well, first we ask for which parts of the domain we, the client, wish computing 
support. Usually we must rely on our domain model to cover far more than 
just those parts. Hence we establish the first bits of domain requirements by 
projecting those parts of both the informal and the formal descriptions onto 
— ie., to become — the domain requirements. 

— Determinations: 

Then we look at those projected parts: If they contain undesired looseness 
or non-determinism, or if parts, like types, are just sorts for which we now 
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wish to state more — not implementation, but “contents” — details, then 
we remove such looseness, such non-determinacy, such sorts, etc. This we 
call determination. 

— Extensions: 

Certain functionalities can be spoken of in the domain but to carry them 
out by humans have either been too dangerous, too tedious, uneconomical, 
or otherwise infeasible. With computing these functionalities may now be 
feasible. And, although they, in a sense “belong” to the domain, we first 
introduce them while creating the domain requirements. We call this domain 
extension. The distinction, thus is purely pragmatic. 

— Initialisations: 

In describing a domain, such as we for example described the “space” of all 
time tables, we must, for each specific time table, designate the “space” of 
all its points of departures and arrivals. If our requirements involve these de- 
parture and arrival points (airports, railway stations, bus depots, harbours), 
then sooner or later one has to initialise the computing system (database) 
to reflect all these many entities. Hence we need to establish requirements 
for how to initialise the computing system, how to maintain and update it, 
how to vet (ie., contextually check) the input data, etc. 

There may be other domain-to-requirements “conversion” steps. We shall, in 
this paper, only speak of these. 

In doing the above we may iterate between the four (or more) domain-to- 
requirements “conversion” steps. 

We now illustrate what may be going on here. But first we need to tak an 
aside: To bring “an entire” domain model” ! That is, the next section (“A Do- 
main Intrinsics Model” ) does not belong to the requirements modelling phase of 
development, but to the domain modelling phase of development. 

A Domain Intrinsics Model: We wish to illustrate the concepts of projection, 
determination, extension and initialisation of a domain requirements from a 
domain. We will therefore postulate a domain. We choose a very simple domain. 
That of a traffic time table, say flight time table. In the domain you could, in 
“ye olde days” hold such a time table in your hand, you could browse it, you 
could look up a special flight, you could tear pages out of it, etc. There is no end 
as to what you can do to such a time table. So we will just postulate a sort, TT, 
of time tables. Airline customers, in general only wish to inquire a time table 
(so we will here omit treatment of more or less “malicious” or destructive acts) . 
But you could still count the number of digits “7” in the time table, and other 
such ridiculous things. So we postulate a broadest variety of inquiry functions 
that apply to time tables and yield values. Specifically designated airline staff 
may, however, in addition to what a client can do, update the time table, but, 
recalling human behaviours, all we can ascertain for sure is that update functions 
apply to time tables and yield two things: Another, replacement time table and 
a result such as: “your update succeeded”, or “your update did not succeed”, 
etc. In essence this is all we can say for sure about the domain of time table 
creations and uses. 
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scheme TI_TBL_0 = 
class 
type 

TT, VAL, RES 
QU = TT ^ VAL 
UP = TT ^ TT X RES 

value 

client_0: TT ^ VAL, client(tt) = let q:QU in q(tt) end 
staff_0: TT ^ TT x RES, staff(tt) = let u:UP in u(tt) end 
timtbLO: TT ^ Unit 
timtbl(tt) = 

(let V = client_0(tt) in timtbLO(tt) end) 

n 

(let (tt',r) = staff_0(tt) in timtbLO(tt') end) 

end 

The system function is here seen as a never ending process, hence the type Unit. 
It internal non-deterministically alternates between “serving” the clients and the 
staff. Either of these two internal non-deterministically chooses from a possibly 
very large set of queries, respectively updates. 

We now return from our domain modelling detour. In the next four sections 
we illustrate a number of domain requirements steps. There are other such steps 
(‘fitting’, etc.) which we will leave un-explained. 

Projections: In this case we have defined such a simple, ie., small domain, so we 
decide to project all of it onto the domain requirements: 

scheme TI.TBL.l = TI.TBL.O 



Determinations: Now we make more explicit a number of things: Time tables 
record, for each flight number, a journey: a sequence of two or more airport visits, 
each designated by a time of arrival, the airport name and a time of departure. 

scheme TI_TBL_2 = 

extend TI_TBL_1 with 
class 
type 

Fn, T, An 

JR' = (T X An X T)* 

JR = {| jr:JR' • len jr > 2 A ... |} 

TT = Fn ffi JR 

end 



where we omit (...) to express further wellformedness constraints on journies. 
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Then we determine the kinds of queries and updates that may take place: 

scheme TLTBL_3 = 

extend TI_TBL_2 with 
class 
type 

Query == mk_brow() | mk_jour(fn:Fn) 

Update == mkJnst(fn:Fn,jr:JR) | mk_delt(fn:Fn) 

VAL = TT 

RES == ok I not_ok 

value 

Mq: Query ^ QU 
Mq(qu) = 
case qu of 

mk_brow() ^ 

Att:TT*tt, 

mk_jour(fn) 

^ Att:TT • if fn 6 dom tt then [ fni-^tt(fn) ] else [] end 

end 

Mu: Update ^ UP 
Mu(up) = 
case qu of 

mkjnst(fn,jr) ^ 

Att:TT • if fn 6 dom tt then (tt,not_ok) else (tt U [ fni-^jr ],ok) end, 
mk_delt(fn) ^ 

Att:TT • if fn 6 dom tt then (tt \ {fn},ok) else (tt,not_ok) end 

end 

end 

And finally we redefine the client and staff functions: 

scheme TI_TBL_4 = 

extend TI_TBL_3 with 
class 
value 

client_4: TT ^ VAL, client_4(tt) = let q:Query in (Mq(q))(tt) end 
stafF_4: TT ^ TT x RES, staff_4(tt) = let u:Update in (Mu(u))(tt) end 

end 

The timtbl function remains “basically” unchanged! 

scheme TI_TBL_5 = 

extend TI_TBL_4 with 
class 
value 

timtbl_5: TT ^ Unit 
timtbl_5(tt) = 

(let V = client_4(tt) in timtbl_5(tt) end) 

n 



end 



(let (tt^,r) = staff_4(tt) in timtbl_5(tt^) end) 
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Extensions: Suppose a client wishes, querying the time table, to find a connection 
betwen two airports with no more than n shift of aircrafts. For n = 0, n = 1 or 
n = 2 this may not be difficult to do “in the domain”: A few 3M Post it’s a human 
can perhaps do it in some reasonable time for n = 1 or n = 2. But what about 
for n = 5. Exponential growth in possibilities makes this an infeasible query “in 
the domain”. But perhaps not using computers. (The example is, perhaps a bit 
contrived.) 



scheme TI_TBL_6 = 
extend TI_TBL_5 with 
class 
type 

Query == ... | mk_conn(fa:An,ta:An,n:Nat) 

VAL = TT I CNS 
CNS = (JR*)-set 
value 

Mq(q) = 
case q of 

mk_conn(fa,ta,n) ^ Att:TT • ... 

end 

end 

where we leave it to the reader to define the “connections” function! 

Initialisations: We remind the reader that this and the immediate three 

Initialisation here means: From a given input of flight journies to create an 
initial time table (ie., an initial database). Ongoing changes to time tables have 
been provided for through the insert and delete operations — already defined. 
In their definition, however, we skirted an issue which is paramount also in 
initialisation: Namely that of vetting the data: That is, checking that a journey 
flies non-cyclically between existing airports, that flight times are commensurate 
with flight distances and type of aircraft (jet, supersonic or turbo-prop), that 
at all airports planes touch down and take off at most every n minutes, where n 
could be 2, but is otherwise an airport parameter. To check some of these things 
information about airports and air space is required. 

scheme TI_TBL_7 = 

extend TI_TBL_6 with 
class 
type 

InitJnp = (Fn X JR)-set 
AP = An Airport 
AS = (An X An) AirCorridor-set 
Number, Length 
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value 

obs_RunWays: Airport ^ Number 
obsJDistance: AirCorridor — > Length 



end 

We leave it to the imagination, skills and stamina of the reader to complete the 
details! Our points has been made: ‘Initialisation’, suddenly uncovers a need 
for enlarging the domain descriptions, and “there is much more to initialisation 
than meets the eye.”^ 



Facet- Oriented Domain Requirements: We may be able to make a dis- 
tinction between “intended” and un-intended inconsistencies and “intended” 
and unintended conflicts. The “intended” ones are due to inherent properties of 
the domain. The un-intended ones are due to misinterpretations by the domain 
recorders or, are “real enough,” but can be resolved through negotiation be- 
tween stake-holders — thus entailing aspects of business process re-engineering 
— before requirements capture has started. 

We thus assume, for brevity of exposition, that un-intended inconsistencies 
and un-intended conflicts have been thus resolved, and that otherwise “sepa- 
rately” expressed perspectives have been properly integrated (ie. ameliorated). 

A major aspect of domain requirements is that of establishing contractual re- 
lationships between the human or support technology ‘agents’ in the environment 
of the “software, ie., the system-to-be”, and the software ‘agents’. As a result 
of a properly completed and integrated domain modelling of support technolo- 
gies, management & organisation, rules & regulations, and human behaviour, we 
have thus identified domain inherent inconsistencies and conflicts. They appear 
as a form of non-determinism. These forms of non-determinism typically need 
either be made deterministic, as in domain requirements determination, or be 
made part of a contract assumed to be enforced by the environment: Namely 
a contract that says: “The environment will promise (cum guarantee) that the 
inconsistency or the conflict will not ‘show up’ !” 

These contractual relationships express assumptions about the interaction 
behaviour — to be further explored as part of the next topic: ‘Interface Re- 
quirements’. If the environment side of the combined system of the “software, 
ie., the system-to-be” does not honour these contractual relationships, then the 
“software, ie., the system-to-be” cannot be guaranteed to act as intended! 

We thus relegate treatment of some facet-oriented domain requirements to 
the requirements capture and modelling stage of interface requirements. 



Towards a Calculus of Domain Requirements: We have sketched a “posit 
& prove calculus” for deriving domain requirements. So far we have identified 

^ Reasonable C code for the input of directed graphs is usually twice the “size” of 
similarly reasonable C code for their topological sorting ! 
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four operations in this “posit & prove calculus”: Projection, determination, ex- 
tension and initialisation. In each derivation step the operation takes two argu- 
ments. One argument is the domain requirements developed so far. The other 
argument is the concerns of that step of derivation: What is, and what is not 
to be projected, what is and what is not to be determined, what is and what 
is not to be extended, respectively what is and what is not to be initialised, 
etc. The “proof” part of the “posit & prove calculus” is a conventional proof of 
correctness between the two arguments. 

We have still to further develop: Identify possibly additional domain require- 
ments derivation operators, and to research and provide further principles and 
detailed techniques also for already identified derivation operations. 

It seems that the sequence of applying these derivators is as suggested above, 
but is that “for sure ?” . 



2.5 Interface Requirements 

By an interface requirements we shall understand those requirements (for a com- 
puting system) which concern very explicitly the “things” ‘shared’ between the 
domain and the machine: In the domain we say that these “things” are the ob- 
servable phenomena: the information, the functions, and/or the events of, or in, 
the domain. In the machine we say that they are the data, the actions, and/or 
the interrupts and/or the occurrence of inputs and outputs of the machine. 
By ‘sharing’ we mean that the latter shall model, or be harmonised with, the 
former. There are other interface aspects — such as “translates” into “bulk” 
input/output, etc. 

But we shall thus illustrate just the first two aspects of ‘sharing’. 



External Vs. Internal ‘Agent’ Behaviours: The objectives of this step of 
requirements development is the harmonisation of external and internal ‘agent’ 
behaviours. 

One the side of the environment there are the ‘agents’, say the human users, 
of the “software-to-be” . On the side of the “software-to-be” there is, say, the 
software ‘agents’ (ie. the processes) that interact with environment ‘agents’. Har- 
monisation is now the act of securing, through proper requirements capture nego- 
tiations, as well as through proper interaction dialogue and “vetting” protocols, 
that the two kinds of ‘agents’ live up to mutually agreed expectations. 

Other than this brief explication we shall not treat this area of requirements 
engineering further in the present paper. 



GUIs and Databases: Assume that a database records the data which reflects 
the topology of some air traffic net, or that records the contents of a time table, 
and assume that some graphical user interface (GUI) windows represent the 
interface between man and machine such that items (fields) of the GUI are 
indeed “windows” into the underlying database. We prescribe and model, as 
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an interface requirements, such GUIs and databases, the latter in terms of a 
relational, say an SQL, database. 

type 

Nm, Rn, An, Txt 

GUI = Nm jft Item 

Item = Txt X Imag 

Imag = Icon | Gurt | Tabl | Wind 

Icon == mkJcon(val:Val) 

Gurt == mk_Gurt(vall:Val*) 

Tabl == mk_Tabl(rn:Rn,tbl:TPL-set) 

Wind == mk_Wind(gui:GUI) 

Observe how the “content” values of icons and curtains are allowed to be any 
values, as now defined: 

Val = VAL I REF | GUI 

VAL = mkJntg(i:Intg) | mkJ3ool(b;Bool) | mk_Text(txt:Text) | mk_Char(c:Char) 

RDB = Rn Trt- TPL-set 
TPL = An TTt VAL 

REF == mk_Ref(rn:Rn,an:An,sel:(An Trt- OVL)) 

OVL == nil I mk_Val(val:VAL) 



Icons effectively designate a system operator or user definable constant or vari- 
able value, or a value that “mirrors” that found in a relation column satisfying 
an optional value (OVL). Similar for curtains and tables. Tables more directly 
reflect relation tuples (TPL). GUIs (Windows) are defined recursively. 

If, for example, the names space values of Nm, Rn, and An, and the chosen 
constant texts Txt, suitably mirror names and phenomena of the domain, then 
we may be on our way to satisfying a “classical” user interface requirement, 
namely that “the system should be user friendly”. 

For a specific interface requirements there now remains the task of relating 
all shared phenomena and data to one another via the GUI. In a sense this 
amounts to mapping concrete types onto primarily relations, and entities of 
these (phenomena and data) onto the icons, curtains, and tables. 



2.6 Machine Requirements 

By machine requirements we understand those requirements which are exclu- 
sively related to characteristics of the hardware to be deployed (and, in cases 
even designed) and the evolving software. That is, machine requirements are, 
in a sense, independent of the specific “details” of the domain and interface 
requirements, ie., “considers” these only with a “large grained” view. 
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Performance Issues: Performance has to do with consumption of computing 
system resources:. Besides time and (storage) space, there are such things as 
number of terminals, the choice of the right kind of processeing units, data 
communication bandwidth, etc. 

Time and Space: Time and (storage) space usually are singled out for particular 
treatment. Designated functions of the domain and interface requirements are 
mandated to execute, when applied, within stated time (usually upper) bounds. 
This includes reaction times to user interaction. And designated domain infor- 
mation are likewise mandated to occupy, when stored, given (stated) quantities 
of locations. 



Dependabilities: Dependability is an “ility” “defined” in terms of many other 
“ilities”. We single out a few as we shall later demonstrate their possible dis- 
charge in the component software system design. 

Availability: There might be situations where a domain description or a domain 
(or interface) requirements prescription define a function whose execution, on 
behalf of a user, when applied, is of such long duration that the system, to other 
users, appear unavailable. 

In the examle of the time table system, such may be the case when the air 
travel connections function searchers for connections: The computation, with 
possible “zillions” of database (cum disk) accesses, “grinds” on “forever” . 

Accessahility: There might be situations where a domain description or a domain 
(or interface) requirements prescription may give the impression that certain 
users are potentially denied access to the system. 

In the example of the time table system, such may be the case when the 
time table process non-deterministically chooses between “listening” to requests 
(queries) from clients and (updates) from staff. The semantics of both the in- 
ternal ( |] ) and the external ( |] ) non-deterministic operators are such as to not 
guarantee fair treatment. 

Other Dependabilities: We omit treatment of the reliability, fault tolerance, ro- 
bustness, safety, and security “ilities”. 

Discussion: We refrain from attempting to formalise the machine requirements 
of availablity and accessability — for the simple reason that whichever way we 
today may know how to formalise them, we do not yet know of a systematic way 
of transforming these requirements into, ie., of “posit & prove calculating” their 
implementations. 

This is clearly an area for much research. 



Maintainabilities: Computing systems have to be maintained: For a number 
of reasons. We single out one and characterise this and other maintenance issues. 
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Adaptability: We say that a computing system is adaptable (not adaptive), wrt. 
change of “soft” and “hard” functionalities, when change of software or hardware 
“parts” only involves “local” adaptations. 

“Locality”, obviously, is our hedge. Not having defined it we have said little, 
if anything. The idea is that whatever changes have to be made in order to 
accomodate replacement hardware or replacement software, such changes are to 
be made in one place: One is able, a priori, to designate these places to within, 
say, a line, a paragraph, or, at most, a page of documentation. 

We shall discuss adaptability further when we later tackle component soft- 
ware design issues. 

Performability: A computing system satisfies a performability requirements, wrt. 
change (usually improvement) of “soft” and “hard” performance issues [time, 
space], when such change only involves “local” changes. 

Correctability: A computing system is correctable (not necessarily correct), wrt. 
debugging “soft” and “hard” bugs, when such change only involves “local” cor- 
rections. 

Preventability: A computing system has its failure modes being preventable 
(not necessarily prevented), wrt. “soft” and “hard” bugs, when regular tests can 
forestall error modes. For hardware, preventive maintenance is an old “profes- 
sion” . Rerunning standard, accumulative test suites, whenever other forms of 
maintenance has been carried out, may be one way of carrying out preventive 
maintenance ? 



Portabilities: By portability we understand the ability of software to be de- 
ployed on different computing systems platforms: From legacy operating systems 
to, and between such systems as (Microsoft’s) Windows, Unix and Linux. 

One can distinguish between the computing systems platform on which it 
may be requirements mandated that development shall take place — in contrast 
to the computing systems platforms on which it may be requirements mandated 
that execution and maintenance shall take place. Etcetera. 

2.7 Feature Interaction Inconsistency and Conflict Analysis 

One thing is to “dream” up “zillions” of “exciting” requirements, whether do- 
main, interface, or machine requirements. Another thing is to ensure that these 
many individually conceived requirements “harmonise”: “Fit together”, ie., do 
not create inconsistencies or conflicts when the “software-to-be” is the basis 
of computations. Proper formal requirements models allow systematic, formal 
search for such anomalies [30,31,29]. Other than mentioning this ‘feature in- 
teraction’ problem, we shall not cover the problem further. But a treatment of 
some aspects of requirements engineering would not be satisfying if it completely 
omitted any reference to the problem. 




Towards Posit & Prove Calculi 



71 



2.8 Discussion 

We have attempted a near-exhaustive listing and partial survey of as complete a 
bouquet of requirements prescription issues as possible. We have done so in order 
to delineate the scope and span of formal techniques, as well as the relations, 
“backward”, to domain descriptions, and, as we shall later see, “forward” to 
software design. 

A major thesis of our treatment, maybe not so fully convincingly demon- 
strated here, but then perhaps more so in our lecture notes [7], is to demon- 
strate these relationships, to demonstrate that requirements, certainly domain 
requirements, can be formalised, and to provide sufficiently refined requirements 
prescription techniques — especially for domain requirements. 

We have tried, in contrast to todays software engineering (including require- 
ment engineering) text books, to provide some principles and techniques for 
structuring the requirements documents to be constructed by requirements en- 
gineers. 



3 Software Design 

Requirements prescriptions do not specify software designs. Where a require- 
ments prescription is allowed to leave open may ways of implementing some 
entities (ie., data) and functions, a software design, initially an abstract one, in 
the form of an architecture design, makes the first important design decisions. 
Incrementally, in stages, from architecture, via program organisation based on 
identified components, to module design and code, these stages of software design 
concretises previously abstract entities and functions. 

Where requirements selected parts of a domain for computerisation by only 
stating such requirements for which a computable representation can be found, 
software design, one-by-one selects these representations. 



3.1 Architectures 

By an architecture design we understand a software specification that impleme- 
nents the domain and, maybe, some of the interface requirements. The domain 
requirements of client_4, stafL4, and timtbl_5, are first transformed, and this 
is just a proposal, as a system of three parallel processes client_arch, stafLarch, 
and timtbLarch. Where client_4 and staff_4, embedded within timtbl_5, we now 
“factor” them out of timtbl_5, and hence we must provide channels that al- 
low client_arch and stafLarch to communicate with timtbLarch. The communi- 
cated values are the denotations, cf. aplets, of query and update commands. 
Whereever client_arch and stafLarch had time tables as arguments they must now 
communicate the function denotations, that were before applied to time tables, 
to the timtbLarch process. 
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scheme ARCH = 
extend ... with 
class 

channel 

ctt QU, ttc VAL, stt UP, tts RES 

value 

system_arch: TT — + Unit, system_arch(tt) = 

client_arch() || staff_arch() || timtbLarch(tt) 

client _arch: Unit ^ out ctt in ttc Unit 

client_arch() = let q:Query in ctt ! Mq(q) ; ttc ? ; client_arch() end 
staff_arch: Unit ^ out stt in tts Unit 

staff_arch() = let u:Update in stt ! Mu(u) ; tts ? ; staff_arch() end 

timtbl_arch: TT — > in ctt,stt out ttc, tts Unit 
timtbl_arch(tt) = 

(let q = ctt ? in ttc ! q(tt) end timtbLarch(tt)) 

D 

(let u = stt ? in let (tt^,r) = u(tt) in tts ! r ; timtbl_arch(tt^) end end) 

end 



Notice how we have changed the non-deterministic behaviour from being internal 
P for timtbl_5 to becoming external [] for timtbLarch. One needs to argue some 
notion of correctness of this. 

An interface requirements was not stated above, so we do it here, namely 
there shall be a number of separate client_arch_l processes, each having its iden- 
tity as a constant parameter. Figure illustrates the idea. 




Architecture: A Time-table with Clients and SU 

Fig. 1. 



^ Figures 1-5 also illustrates the use of a diagrammatic language. It is very closely 
related to the CSP subset of RSL. Other than showing both scheme ARCH and 
Figure 1 we shall not “explain” this diagrammatic language — but it appears to be 
straightforward. We shall hence ‘reason’ over constructs (complete diagrams) of this 
diagrammatic language. 
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The system_arch_l now consists of n client_arch_l parallel processes in par- 
allel with a basically unchanged stafLarch_l process and a slightly modified 
timtbl_arch_l process. The slightly modified timtbl_arch_l process expresses will- 
ingness to input from any client_arch_l process, in an external non-deterministic 
manner. Etcetera: 

value 

n:Nat 

type 

Cldx = {| l..n 1} 
channel 

ctt[l..CIdx] QU, ttc[l..CIdx] VAL, stt UP, tts RES 

value 

system_arch_l: TT ^ Unit 

system_arch_l(tt) = || { client _arch_l(i) | i:CIdx } || stafF_arch_l() || timtbl_arch_l(tt) 
client_arch_l: Cldx out ctt in ttc Unit 

client_arch_l(i) = let qiQuery in ctt[i] ! Mq(q) ; ttc[i] ? ; client_arch_l(i) end 
staff_arch_l: Unit — > out stt in tts Unit 

stafF_arch_l() = let uiUpdate in stt ! Mu(u) ; tts ? ; staff_arch_l() end 

timtbl_arch_l: TT ^ in { ctt[i],stt[i] i:CIdx } out ttc, tts Unit 
timtbl_arch_l(tt) = 

[] { let q = ctt[i] ? in ttc[i] ! q(tt) end timtbL(tt) | i:CIdx } 

[] (let u = stt ? in let (ttV) = u(tt) in tts ! r ; timtbl_arch_l(tt^) end end) 



3.2 Component Design 

By a component design (as action) we understand a set of transformations, 
from a software architecture design, that implements the remaining interface 
requirements and major machine requirements, to the component design (as 
document). Whereas a software architecture design may have been expressed in 
terms of rather comprehensive processes, component design, as the name inti- 
mates, seeks to further decompose the architecture design into more manageable 
parts. Object modularisation (ie., module design) goes hand-in-hand with com- 
ponent design, but takes a more fine-grained approach. We are not yet ready, in 
our research, to relate these “posit & prove transformations” to the refinement 
calculus of for example Ralph Johan Back [21]. There are (at least) points: First 
there are too many issues predicating which refinements to choose. These issues 
represent the judicious prioritisation between a multitude of domain, interface 
and machine requirements: Which to consider and implement before others ? 
Secondly the “refinement steps” illustrated next seem rather large. Hence for a 
proper refinement calculus to be proposed we need express the “large” steps, it 
seems, in terms of sequences of “smaller” steps. We are far from ready to embark 
on such an endeavour. 
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This is why we have used the phrase: Posit Prove Calculus in the title of 
this communication. 

One may say, colloquially speaking, that where component design decom- 
poses a software design (and as guided by (remaining interface and by) machine 
requirements) into successively smaller parts, module design composes these 
parts from initially smallest modules. The former is, so-to-speak “top-down”, 
where the latter seems more “bottom-up”^. 

At this stage we will just sketch the introduction of new processes that handle 
the machine requirements of accessability, availability and adaptability. But, as 
it turns out, it is convenient to first tackle an issue of many users versus just one 
interface. 



Multiplexing: Instead of designing a time table subsystem that must cater to 
n + 1 users we design one that caters to just two users. Hence we must provide 
a multiplexor, a component which provides for a more-or-less generic interface 
between, “to one side” n identical (or at least similar) processes, and, “to the 
other side” one process. 

Figure 2 illustrates the idea. 




Program Organisation with Clients, Muitipiexor, Staff, Timetabie, and Channeis 
Fig. 2. 



What we have done is to factor out the external non-deterministic choice 
amongst client process interactions, as documented in timtbl_4 by the distributed 
choice: 

^ But we normally refrain from these “figurations” as they depend on how one visu- 
alises matters: As a root of further roots, or as a tree of branches. 
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[] { let q = ctt[i] ? in ... end | i:CIdx } 

from that function into the mpx function. The external non-deterministic choice 
(remaining) among the one “bundled” client input and the staff will, see next, 
below, later be “moved” to an arbiter function. 

We call such a component a multiplexor and leave its definition to the reader. 

Accessability: To “divide & conquer” between requests for interaction with 
the time table process from either the (“bundled”) clients (via the multiplexor) 
or the staff, we insert an arbiter component. 

Figure 3 illustrates the idea. 




Program Organisation with Ciients, Multipiexor, Arbiter, Staff, Timetabie, and Channeis 

Fig. 3. 



Its purpose is to create some illusion of fairness in handling non-determinism. 
If the arbiter ensures to “listen fairly” to the (“bundled”) client and the staff 
“sides” , for example for every / times it handles requests from the client side to 
then switch to handling one from the staff side, then perhaps some such fairness 
is achieved. The determination of /, or, for that matter, the arbiter algorithm, is 
subject to statistical knowledge about the traffic from either side and the service 
times for respective updates. 

This issue of requiring ‘fairness’ also “spills” over to the multiplexor function. 
Letting the arbiter also handle urgency of requests is natural. It would, in 
our view, be a further ‘accessability’ requirements. 

We leave further specification to the reader. 

Availability: The only component (ie., process) that may give rise to “loss of 
availability” is the time table process. Computing, for example the “at most n 
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change of flight” connections may take several orders of magnitude more time 
than to compute any other query or update. The idea is therefore to time- 
share the time table process, and, as a means of exploiting this time-sharing, to 
redesign (also) the multiplexor component and add a queue component. 

Figure 4 illustrates the idea. 




Program Organisation with Clients, Multiplexor, Queue, Arbiter, Staff, time shared Timetable, and Channels 

Fig. 4. 



The multiplexor is now to accept successive requests for interaction from 
multiple clients (or even the same client). And the queueing component is to 
queue outstanding requests that are, at the same time sent to the time table 
process. It may respond to previously received requests, “out-of-order”. The 
queueing component will track “back to which clients” request-responses shall 
be returned. 

We leave further specification to the reader. 

Adaptability: We have seen how the software design has evolved, on paper, 
in steps of component design development, into successively more components. 
Each of these, including those of the client, time table and staff processes may 
need be replaced. The client and staff components in response to new terminal 
(ie., PC) equipment, and the time table process in response, say to either new 
database management systems or new disks, or “both and all” ! 

If each of these components were developed with an intimate knowledge of 
(and hence dependency on) the special interfaces that these components may 
offer, then we may And that adaptability is being compromised. Hence we may 
decide to insert between neighbouring components so-called connectors. These 
are in fact motivated last, as in this “example sample development”, but are suit- 
ably abstractly developed first. They “set standards” for exchange of information 
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and control between components. That is, they define abstract, simple protocols. 
Once all components have been “inserted” one may refine the protocols to suit 
these compponents. 

Figure 5 illustrates the idea. 




Program Organisation with Clients, Multiplexor, Queue, Arbiter, Staff, Timetable, Connectors and Channels 

Fig. 5. 



We leave further specification to the reader. 



Architecture Vs. ‘Componentry’: We refer to work by David Garlan and 
his colleagues, work that relate very specifically to the above [3, 1, 13,4, 22,2, 12, 
5]. What Garlan et al. call software architecture is not what we call software 
architecture. Ours is more abstract. Theirs is more at the level of interfacing 
components, that is of the connectors mentioned above under Adaptability. The 
GMU (ie., the Garlan et al.) work is much appreciated. 

3.3 Towards “Posit & Prove Calculi” for Architecture and 
Component Structure Derivation 

We have sketched a “posit & prove calculus” for deriving component structures. 
In each step of derivation the “operations” of the “component structure calculus” 
takes two “arguments”. One “argument” is a specific machine (or interface) 
requirement. The other “argument” is a component structure (or, for the first 
step, the software architecture). The result of applying the “operation” is a new 
component structure. 

We have still to develop: Identify, research and provide principles and more 
detailed techniques for when and how to deploy which machine (or interface) re- 
qirements to which component structures. To wit: “Should one apply the ‘avail- 
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ability’ requirements before or after the ‘accessability’ requirements, etc. It is not 
yet clear whether the adaptability (and other maintenance “ility” ) requirements 
should be discharged, before, in step with, or after the discharge of each of the 
dependability “ilities”. Etcetera. 

We have not covered in this paper any “posit & prove calculus” aspects of 
deriving architectures from domain requirements. 

4 Conclusion 

4.1 Summary 

We have completed a “tour de force” of example developments. Stepwise ‘refine- 
ments’ of domain descriptions, here for time tables, and phasewise transforma- 
tion of domain descriptions into requirements prescriptions and the latter into 
stages of software designs: Architecture and component designs. It is soon time 
to conclude and to review our claims. 

4.2 Validation and Verification 

We have presented aspects of an almost “complete” chain of phases, stages and 
steps of development, from domains via requirements and software architecture 
to program organsation in terms of components and connectors. In all of this 
we have skirted the issues of validation and verification: Validating whether 
we are developing the right “product”, and veryfying whether we develop that 
“product” right. 

An issue that ought be mentioned, in passing, is that of some requirements, 
typically machine requirements, only being implementable in an approximate 
manner. One may, for example, have to check with runtime behaviour as to the 
approximation with which such machine requirements have been implemented 
[ 11 ]. 

Obviously more than 30 years of program correctness have not gone behind 
our back: With formalisations of many, if not most, phases, stages and steps 
it is now easier to state lemmas and theorems of properties and correctness. 
Properties of individual descriptions, prescriptions and specifications; correctness 
of one phase of development wrt. to the previous phase, respectively the same 
for stages and steps. 

We have shown how to develop software “light”. That is: Formally specify- 
ing phases, stages and steps, and, in a few, crucial cases, formulating lemmas 
and theorems (concerning “this and that” ) . We have found that developing soft- 
ware “light” seems to capture “most” development mistakes. In any case it is 
appropriate to end this, the ‘triptych’ section with the following: 

Let T>, TZ and S stand for related 2?omain descriptions, 7?.equirements pre- 
scriptions, repectively (Software specifications. Correctnes of the (Software with 
respect to its T^equirements can then be expressed as: 



V,S h 'Ti 
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which, in words, imply: Proofs of correctness of S with respect to TZ typically 
require assumptions about the domain V. 

What could those assumptions be ? Are they not already part of the require- 
ments ? To the latter the answer could be no, in which case it seems that we may 
have projected those assumptions “away” ! And then these assumptions could be 
expressed, in the domain descriptions, in the form, for example, of constrained 
human or support technology behaviours, or of management behaviours, or they 
could be in the form of script languages in which to express rules & regulations, 
or they may be properties of the Pomain that can be proved in V. 

In [23] van Lamsweerde complements the above approximately as follows (our 
interpretation'^) : 

Let A stand for a notion of ‘Accuracy’: Non- functional goals requiring that 
the state of the input and output software objects accurately reflect the state 
of the corresponding monitored, respectively controlled objects they represent, 
and let Q stand for the set of goals: 

A,S \= TZ with: A,S false and T>,TZ\= Q with: T>,TZ'^ false 

We find this a worthwhile “twist”, and expect more work done to fully under- 
stand and exploit the above. 



4.3 Proper Identification of Components 

“Varieties of requirements prescriptions lead to more stable identification of 
proper components” : We hope that the development of components and con- 
nectors for the, albeit simple minded time table system of Section 3’s subsection 
on ‘Component and Object Design’, “visualised” in Figures 2-5, can illustrate 
this claim: Each of the components — other than the client, time table and staff 
components, are components that relate primarily to machine (or, not shown, 
interface) requirements. Machine requirements are usually almost identical from 
application to application, and hence their components are “usually” reusable. 
But also the domain requirements components of clients, staff and time-shared 
time table, “cleaned” for all concerns of interface and machinerequirements, now 
appear in a form that is easier to parameterise and thus make reusable. 



4.4 A Programme of Current Research 

We briefly recall that there seems to be interesting research issues in better un- 
derstanding and providing methodological support for the derivation of domain 
requirements and the derivation of component structures. 

As there are unexplained occurrence of 22 in van Lamsweerde formula: He addition- 
ally uses As where we use 22 




80 



Dines Bj0rner 



4.5 Acknowledgements 

The author is tremendously grateful for a very careful review of a referee. I wish 
to state that many of the very reasonable concerns of the referee are indeed very 
valid concerns also of mine. Space, however, did not permit me, in a paper as 
“far sweeping” as this has become, to address each and all of these concerns. 

4.6 A Caveat 

This paper represents work in progress. It is based on presentations of topics for 
discussion at the IFIP Working Group 2.3. Such presentations are necessarily of 
“work in progress” — with the aim of the presentation being to solicit comments. 
As just said above, the anonymous referee has just done that. Thanks. 

References 

1. G. Abowd, R. Allen, and D. Garlan. Using style to understand descriptions of soft- 
ware architecture. SIGSOFT Software Engineering Notes, 18(5):9-20, December 
1993. 

2. G.D. Abowd, R. Allen, and D. Garlan. Formalizing style to understand descrip- 
tions of software architecture. ACM Transactions on Software Engineering and 
Methodology, 4(4):319-364, Oct 1995. 

3. R. Allen and D. Garlan. A formal approach to software architectures. In 
IFIP Transactions A (Computer Science and Technology); IFIP Wordl Congress; 
Madrid, Spain, volume vol.A-12, pages 134-141, Amsterdam, Netherlands, 1992. 
IFIP, North Holland. 

4. R. Allen and D. Garlan. Formalizing architectural connection. In 16th International 
Conference on Software Engineering (Cat. No.QfCHSfOQ-O); Sorrento, Italy, pages 
71-80, Los Alamitos, CA, USA, 1994. IEEE Comput. Soc. Press. 

5. R. Allen and D. Garlan. A case study in architectural modeling: the AEGIS system. 
In 8th International Workshop on Software Specification and Design; Schloss Velen, 
Germany, pages 6-15, Los Alamitos, CA, USA, 1996. IEEE Comput. Soc. Press. 

6. Dines Bjprner. Domain Engineering: A “Radical Innovation” for Systems and 
Software Engineering ? In Verification: Theory and Practice, volume 2772 of Lec- 
ture Notes in Computer Science, page 54 pages, Heidelberg, October 7-11 2003. 
Springer- Verlag. The Zohar Manna International Conference, Taormina, Sicily 29 
June - 4 July 2003. 

7. Dines Bjprner. The SE Book: Principles and Techniques of Software Engineering, 
volume I: Abstraction & Modelling (750 pages), II: Descriptions and Domains (est.: 
500 pages), HI: Requirements, Software Design and Management (est. 450 pages). 
[Publisher currently (March 2003) being negotiated], I: Fall 2003, II: Spring 2004, 
HI: Summer/Fall 2004 2003-2004. 

8. A. Dardenne, S. Fikas, and Axel van Lamsweerde. Goal-Directed Concept Ac- 
quisition in Requirements Elicitation. In Proc. IWSSD-6, 6th Inti. Workshop on 
Software Specification and Design, pages 14-21, Como, Italy, 1991. IEEE Computer 
Society Press. 

9. A. Dardenne, Axel van Lamsweerde, and S. Fikas. Goal-Directed Requirements 
Acquisition. Science of Computer Programming, 20:3-50, 1993. 




Towards Posit & Prove Calculi 



81 



10. R. Darimont and Axel van Lamsweerde. Formal Refinement Patterns for Goal- 
Driven Requirements Elaboration. In Proc. FSE’4, Fourth ACM SIGSOFT Symp. 
on the Foundations of Software Enginering, pages 179-190. ACM, October 1996. 

11. M. Feather, S. Fikas, Axel van Lamsweerde, and C. Ponsard. Reconciling System 
Requirements and Runtime Behaviours. In Proc. IWSSD’98, 9th Inti. Workshop 
on Software Specification and Design, Isobe, Japan, April 1998. IEEE Computer 
Society Press. 

12. D. Garlan. Formal approaches to software architecture. In Studies of Software 
Design. ICSE ‘93 Workshop. Selected Papers, pages 64-76, Berlin, Germany, 1996. 
Springer- Verlag. 

13. D. Garlan and M. Shaw. An introduction to software architecture, pages 1-39. 
World Scientific, Singapore, 1993. 

14. Joseph A. Goguen and M. Girotka, editors. Requirements Engineering: Social and 
Technical Issues. Academic Press, 1994. 

15. Joseph A. Goguen and C. Linde. Techniques for Requirements Elicitation. In Proc. 
RE ’93, First IEEE Symposium on Requirements Engineering, pages 152-164, San 
Diego, Galif., USA, 1993. IEEE Computer Society Press. 

16. S. J. Greenspan, John Mylopoulos, and A. Borgida. A Requirements Modelling 
Language. Information Systems, ll(l):9-23, 1986. (About RML). 

17. A. Hunter and B. Nuseibeh. Managing Inconsistent Specifications: Reasoning, 
Analysis and Action. ACM Transactions on Software Engineering and Methodol- 
ogy, 7(4):335-367, October 1998. 

18. John Mylopoulos, L. Chung, and B. Nixon. Representing and Using Non- 
Functional Requirements: A Process-oriented Approach. IEEE Trans, on Software 
Engineering, 18(6):483-497, June 1992. 

19. John Mylopoulos, L. Chung, and E. Yu. From Object-Oriented to Goal-Oriented 
Requirements Analysis. CACM: Communications of the ACM, 42(l):31-37, Jan- 
uary 1999. 

20. B. Nuseibeh, J. Kramer, and A. Finkelstein. A Framework for Expressing the Re- 
lationships between Multiple Views in Requirements Specifications. IEEE Trans- 
actions on Software Engineering, 20(10):760-773, October 1994. 

21. Ralph-Johan Back and Joakim von Wright. Refinement Calculus: A Systematic 
Introduction. Graduate Texts in Computer Science. Springer- Verlag, Heidelberg, 
Germany, 1998. 

22. C. Shekaran, D. Garlan, and et al. The role of software architecture in requirements 
engineering. In First International Conference on Requirements Engineering ( Cat. 
N0.94THO6I3-O); Colorado Springs, CO, USA, pages 239-245, Los Alamitos, CA, 
USA, 1994. IEEE Comput. Soc. Press. 

23. Axel van Lamsweerde. Requirements Engineering in the Year 00: A Research Per- 
spective. In Proceedings 22nd International Conference on Software Engineering, 
ICSE’2000. IEEE Computer Society Press, 2000. 

24. Axel van Lamsweerde, R. Darimont, and E. Letter. Managing Conflicts in Goal- 
-Driven Requirements Engineering. IEEE Transaction on Software Engineering, 
1998. Special Issue on Inconsistency Management in Software Development. 

25. Axel van Lamsweerde and E. Letier. Integrating Obstacles in Goal-Driven Require- 
ments Engineering. In Proe. ICSE-98: 20th International Conference on Software 
Enginereering, Kyoto, Japan, April 1998. IEEE Gomputer Society Press. 

26. Axel van Lamsweerde and L. Willemet. Inferring Declarative Requirements Spec- 
ification from Operational Scenarios. IEEE Transaction on Software Engineering, 
pages 1089-1114, 1998. Special Issue on Scenario Management. 




82 



Dines Bj0rner 



27. Axel van Lamsweerde and L. Willemet. Handling Obstacles in Goal-Driven Re- 
quirements Engineering. IEEE Transaction on Software Engineering, 2000. Special 
Issue on Exception Handling. 

28. E. Yu and John Mylopoulos. Understanding ’’why” in Software Process Modelling, 
Analysis and Design. In Proc. 16th ICSE: Inti. Conf. on Software Engineering, 
Sorrento, Italy, 1994. IEEE Press. 

29. Pamela Zave. Classification of Research Efforts in Requirements Engineering. ACM 
Computing Surveys, 29(4):315-321, 1997. 

30. Pamela Zave and Michael A. Jackson. Techniques for partial specification and spec- 
ification of switching systems. In S. Prehn and W.J. Toetenel, editors, VDM’91: 
Eormal Software Development Methods, volume 551 of LNCS, pages 511-525. 
Springer- Verlag, 1991. 

31. Pamela Zave and Michael A. Jackson. Requirements for telecommunications ser- 
vices: an attack on complexity. In Proceedings of the Third IEEE International 
Symposium on Requirements Engineering (Cat. No.97TB100086), pages 106-117. 
IEEE Comput. Soc. Press, 1997. 




Distributed Concurrent Object-Oriented 

Software* 



Manfred Broy 



Institut fiir Informatik 
Technische Universitat Miinchen 
D-80290 Miinchen, Germany 
broy@in . turn . de 



Abstract. In software engineering object-oriented development is to- 
day the most popular programming and design approach. However, in 
contrast to Dahl’s original ideas object-orientation of today does not 
manage to address the needs of today’s software construction in such a 
radical and fundamental way as needed in highly distributed interoperat- 
ing software applications. In the following, we extend object-orientation 
to asynchrony and distribution for engineering large distribnted software 
systems. We show how object-oriented techniques can be extended to a 
programming methodology and software engineering for concurrent dis- 
tributed systems. This is strictly in the spirit of Ole-Johan Dahl. 



1 Introduction 

Object-orientation was fundamentally invented by Ole-Johan Dahl and Kristen 
Nygaard by their design of the programming language Simula 67 (see [Sim- 
ula 67]). Before that, most programming languages were mainly influenced ei- 
ther by the commands of machine languages or by the logical foundations of 
computability such as A-calculus. Only gradually programming languages were 
gaining step by step more abstract views of data and control structures. How- 
ever, also these languages were mainly devoted to concepts of programming in 
the small and sequential, noninteractive programs. Typically, I/O, for instance, 
was considered a minor issue and therefore not part of the programming language 
definition for instance in ALGOL. 

Simula 67 introduced radically new ideas by its concepts of co-routines and 
classes. Such an approach to programming and software development was badly 
needed to master the requirements of the development of large complex software 
systems, distributed over many computers connected by high-speed networks 
and thus operating concurrently and interacting asynchronously. These issues 
are addressed by the idea of distributed object-orientation as formulated for the 
first time in Simula 67. 

Of course, in Simula 67 these ideas were realized by allowing objects to be 
co-routines, which was the best way at that time to imitate concurrent processes. 

’’ Dedicated to Prof. Ole-Johan Dahl 



O. Owe et al. (Eds.): From OO to FM (Dahl Festschrift), LNCS 2635, pp. 83—95, 2004. 
© Springer- Verlag Berlin Heidelberg 2004 
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Once you think of the objects as being independent of each other, concurrency 
among the actions performed by these objects is natural and almost inevitable. 
In today’s world the obvious way would be to let (active) objects be concurrent 
processes, and one would obtain a distributed system by a set of objects running 
in parallel, interacting by remote method calls. Thus, the concepts of threads of 
Java (sharing the same object attributes) is not following the original 00 ideas. 

In the last three decades of software engineering object-orientation developed 
into the most popular programming and design approach. Object-orientation, it 
is claimed, offers better structuring features and more flexible concepts than 
conventional imperative, functional, or logical programming styles — especially 
for structuring programs as well as development and programming in the large. 

Software development techniques and methods of today have to cope with a 
number of difficulties such as 

— the growing complexity and size of software applications, 

— interoperability demands, 

— applications that are executed on large distributed networks, 

— the long term perspective of legacy software systems being in operation over 

30 years or more in a still quickly developing technology with rapidly chang- 
ing requirements. 

Therefore development in the large, management of change, and interoper- 
ability are key issues in software development and programming. 

Unfortunately, object-orientation as mostly applied in practice today does 
not manage to address these needs of software construction of today in such 
a radical and fundamental way as intended by Ole-Johan Dahl. In many re- 
spects, object-orientation stays within the conventional approach to program- 
ming, mainly influenced by the sequential stand-alone machines of the early 
sixties. 

One might object to those claims by saying that, for instance, Java as a recent 
object-orientated programming language is a modern programming language 
that addresses all the needs of today. However, being certainly an advantage over 
some of the programming languages available so far, Java is in many respects 
a rather conventional language. Moreover, the success of Java is not only due 
to its object-orientation. It is also due to its concept of portability and code 
mobility guaranteed by the idea of byte code, which is quite independent of 
obj ect-orient ation . 

In the following we concentrate our discussion onto the following aspects of 
software development: 

(1) interface abstraction and interaction 

(2) concurrency and distribution 

In particular, we discuss which interface abstractions are possible for object- 
oriented programs and how that relates to concurrency and distribution. 

Why is the issue of distribution and concurrency so important? If we assume 
that a software is executed on a large network of computers where response 
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times and transmission time is unpredictable a sequential execution model is 
not appropriate. 



2 Object-Orientation in Practice Today — 

Its Characteristics 

Let us begin our discussion by shortly rephrasing the main characteristics of 
object-orientation. Object-orientation is based on the following major concepts 
and principles: 

— classes with attributes and methods as the major units for describing and 
structuring programs, 

— access interfaces in terms of methods of objects and their attributes described 
by classes, 

— creating objects as instances of classes, 

— encapsulation of data and state represented by programming variables called 
attributes in classes and objects, 

— persistence, meaning the durable storage of local attribute values within 
objects between method invocations, 

— data abstraction and implementation hiding, 

— identifying and addressing objects by object identifiers, 

— inheritance and polymorphism. 

One of the main claims of object-orientation is to provide the capabilities 
and potentials to support the following recognized design principles 

— modularity of interfaces by state encapsulation, 

— data abstraction, 

— information hiding, 

— dynamics and flexibility by object instantiation, 

— reusability by inheritance and aggregation, 

— well-specified interfaces. 

Object-orientation is advocated both as a programming paradigm supported 
by a number of object-oriented programming languages and as a software de- 
velopment method supporting the entire spectrum of analysis, design, and im- 
plementation. In particular, in network applications such as the Internet or 
client/server systems object-orientation is claimed to be the better program- 
ming technique, superior to other programming styles. 

In fact, object-oriented programming languages dominate these application 
areas. Java, for instance, provides the idea of portability and code mobility as a 
decisive feature in Internet applications. 

In spite of the claims and the popularity of object-orientation in practice, 
there are severe shortcomings in object-orientation as it is used in practice today. 
These are in particular the limitations of object-oriented programming to: 
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— intrinsically sequential execution models following the paradigm of sequential 
control flow of procedural programs, 

— code inheritance with a danger of violating the principle of information hid- 
ing and data abstraction, 

— missing interface specification techniques for classes, 

~ missing concept of composition of classes into composite classes, 

— instantiation of objects via references, 

— missing concept of a component as a basis for software architectures. 

Thus object-oriented programming languages of today miss some of the essen- 
tial points of Simula 67. In fact, recent object-oriented programming languages 
offer a number of extensions to classical object-orientation to overcome some of 
these shortcomings. For instance, the syntactic interfaces of classes provide a 
useful concept for interface description. However, for most object-oriented lan- 
guages abstract semantic interface description concepts do not exist. They only 
offer syntactic notions of interfaces. In fact, experiments and experiences with 
object-oriented frameworks show crucially the weakness of current practice of 
object-orientation in that respect. 

The object-oriented paradigm as it is found in many object-oriented pro- 
gramming languages of today is inherently sequential. The reason lies in the 
interaction mechanism between objects, called method invocations, which are 
nothing but procedure calls. This way object-oriented programs have to be seen 
as operating on a large state space for which — according to encapsulation — 
only special scopes are introduced such that the access to attributes is only 
possible inside of the bodies of the respective classes. The effect of a method 
invocation including all the subinvocations of methods during the execution of 
the call has to be described as one state change on this global state space. This 
concept makes the execution model inherently sequential since all calls have to 
be seen as atomic actions. 

The introduction of parallelism and concurrency brings in all the classical 
difficulties and complexities of shared memory parallelism such as the question 
which actions are indivisible, how to co-ordinate and synchronize and how to 
express waiting. The classical ways to introduce concurrency into state based 
systems do not lead to the high level abstract models of the real world as advo- 
cated and claimed by the basic philosophy of object-orientation. 

However, most applications of today run in a highly concurrent distributed 
environment in networks of computers. Therefore, object-oriented programs have 
to interact and react to many concurrent activities. As a result, we want to model 
explicitly concurrent activities in object-oriented programs. 

In the original work on Simula, it was clearly stated that an object would in 
general have its own activity, as well as data and procedure (methods). Objects 
with activity were referred to as “independent processes” , and objects without 
activity were called passive. “Simula I” used the keyword activity (see [Sim- 
ula 67]). 
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3 Concurrent Open Systems — Their Characteristics 

Concurrent distributed systems show a number of characteristics that make them 
complex, and at the same time, flexible. These characteristics include the fol- 
lowing notions: 

— interaction 

— distribution and structure 

— concurrency 

Nonconcurrent, noninteractive programs — sometimes called transforma- 
tional programs — support powerful abstractions. They can be seen as functions, 
in functional programming between arbitrary types, in state-based programs as 
functions between states. In concurrent systems, interaction means that a sys- 
tem does not get all its input initially at the beginning of the computation and 
also that it does not produce all its output only at the end of a computation. 
Input is given step by step to the system, output is generated in response to 
portions of the input step by step. In fact, some of the input may depend on the 
output produced so far if a system runs in a feedback loop. Therefore to model 
the behavior of an interactive system we have to model it as a state transition 
system, or as a function or, relation on streams. 

In the presence of concurrency, it is crucial to fix the granularity of a system 
because this determines for the state transition system at which intermediate 
state some interaction can take place such that input is accepted and output is 
produced. This is closely related to the issue of abstraction. In a noninteractive 
program we may abstract fully from the computation meaning the intermediate 
states generated in the course of the computation. In a concurrent, interactive 
program we have to represent all the intermediate states in which interaction can 
take place and this way may chance the course of the computation. Therefore 
the granularity of the state transition is essential. It determines which states are 
relevant for the interaction. 

4 Object-Oriented Programming and Concnrrency 

In this section we argue about the question whether object-oriented programs 
differ from concurrent interactive programs or not. We argue that object-oriented 
programs show all the characteristics of interactive programs, but do not address 
concurrency properly. In that respect we conclude that although object-oriented 
programs do not support better abstractions than interactive concurrent pro- 
grams they do not exploit all possibilities of concurrency, hierarchy, asynchronous 
communication, and composition. 

We see this as severe shortcomings of today’s practice object-oriented pro- 
gramming. In particular, we argue that according to these deficiencies object- 
orientation fails to address some of the requirements for a programming language 
and technique needed for writing large distributed software systems running on 
networks with long communication delays. 
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4.1 Classes as State Machine Descriptions 

A class manifests the basic idea of a module in object-orientation. Classes are 
the fundamental building blocks in object-oriented programs. In some sense they 
are the only structuring means in object-orientation. They have to play the role 
of components although they are too fine grained for that. 

For an interface specification we have to be able to describe the behavior of 
a component in an interface view. This means that we describe the observable 
behavior of a class. This is a description that identifies under what circumstances 
two different classes can be used in the same environment without any observable 
difference in their behavior. Such a notion is mandatory for a top down as well 
as for a bottom up specification and design approach. 

For classes and objects, however, a simple description of their observable be- 
havior is surprisingly complicated. The reason lies in the interaction mechanism 
between objects, called method invocations, which are, of course, nothing but 
procedure calls. Method invocations may change the state, given by values of 
the attributes of objects. They may also result in further invocations of methods 
and, therefore, change not only the state of the object addressed by the method 
invocation but, in addition, the state of other objects. This way method invoca- 
tions in object-oriented programs have to be seen as operations on a large state 
space — the global program state. In contrast to the principle of state encap- 
sulation, by object-orientation only special scopes are introduced such that the 
access to attributes is only possible inside of the bodies of the respective classes 
or name space. The effect of a method invocation including all the subinvoca- 
tions of methods during the execution of the call has to be described as one state 
change on the global state space. 

The specification of the observable behavior of classes and objects runs into 
all the difficulties of the description of distributed interactive systems — ex- 
cept issues of concurrency and action granularity (see below). In fact, object- 
orientation introduces by its concept of a class nearly everything needed and 
typical for concurrent interactive program execution, however, without being 
brave enough to carry out the final step into concurrency. 

Ole-Johan Dahl’s work on abstract specification of concurrent objects by 
means of histories, has to be mentioned as a possible solution towards “missing 
interface techniques for classes”, and gives an abstract “interface view” as there 
is no other abstract state than that captured by the history. As the abstract state 
at any given time is reflected by a finite history, Ole-Johan Dahl was building 
up specification techniques around finite traces, and a central idea was to use 
right-append as a generator (in contrast to CSP) in order to describe new actions 
in terms of the history (thereby avoiding recursive definition of processes). For 
reasoning about calls that trigger other calls, Ole-Johan Dahl would separate 
initiation of a method call from its termination into two separate events. The 
semantics and rules for parallel composition in this setting has been described 
and pursued by several groups. Ole-Johan Dahl himself was mostly concerned 
with safety reasoning, using the concept of quiescence to deal with liveness, but 
others have done more general work towards liveness. 
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4.2 Interface Views onto Objects 

Basically, there are two interface abstractions for object-oriented programs: 

(1) Closed view: each method call is seen as one indivisible step defining a state 
transition for the object and all the objects changed by submethod calls. 

(2) Open view: each method call consists of a sequence of steps, consisting of 
submethod calls and the state changes between the submethod calls. 

In the presence of concurrency and distribution the closed view is not appro- 
priate. 

The early “Dahl School” on reasoning about 00 systems builds on the idea 
of limiting direct access to attributes of an object from outside, either disallowing 
all remote variable access or allowing access to a some (seen as an abbreviation 
for implicit read and write operations) . Keywords were also added to the Simula 
standard in order to control this. This means that one may give local invariants in 
a class and prove that a class invariant is established and maintained, by looking 
at the text of the class itself (and super-classes). When subclassing is restricted 
so that super-invariants are respected, reasoning about concurrent objects may 
be done without looking at the global state space: Hoare reasoning can be done 
locally in each class (implementation), and reasoning about a (sub)system of 
concurrent objects can be done by means of sets of possible traces (consisting 
of events reflecting the methods calls up to certain point in time). In particular, 
for concurrent objects there is no need for a reasoning about the global state. 



4.3 Interaction Patterns 

A typical property of most approaches to object-oriented programming is the 
use of methods (like procedures in conventional programming languages) with 
their method call and method return pattern of interaction. As long as there 
is no concurrency this pattern is sufficient, and at the same time simple and 
well-structured. Fig. 1 gives an idea of a simple method call hierarchy. 

We get a slightly more complex call cascade if a call leads to a call of a 
method of the initially calling object. 

In interactions by method calls, every call is eventually preceded by a return 
(we exclude for the moment the possibility of nontermination of method calls). 
In the presence of concurrency and distribution of the computing entities of net- 
works with larger communication delays we immediately run into troubles. Since 
the computing entities may run concurrently and communication and calculation 
may take some time, a scheme as in Fig. 1 may no longer be acceptable. Keeping 
the idea of method calls we have to work differently. Fig. 3 shows method calls 
that mimic asynchronous communications. 

But Fig. 3 is no longer a pattern of sequential method calls. In sequential 
method calls exactly one entity is active at a time and control is passed by 
the method calls and the return messages. Now several components are active 
concurrently. This leads to the question, what it means if an object, that is active 
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Fig. 1. Typical Method Call Cascade 




Fig. 2. Method call cascade with recursive subcalls 




Fig. 3. Method call cascade to mimic asynchronous interaction 
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receives another method call. The sequential execution model for object-oriented 
systems is simple and clear. Each computing entity, and each object, is inactive, 
until a method call activates it. Then it calculates until it either returns from 
the method call or issues a method call itself, named a subcall. Then it stays 
inactive until it is called again or the submethod call returns. 

In the presence of concurrency this simple idea is no longer sufficient, because 
a method call may arrive while an object is active. Also in Dahl’s later work 
on specification of 00-systems, it is suggested that objects may be concurrent 
processes, interacting by method calls (with protected variables), see for instance 
the lift example [Dahl, Owe 91]. 

This leads to the question when and how an object accepts the method call. 
Basically, there are three possible answers: 

(1) interrupt: the object immediately stops its current calculation and works 
on the incoming method calls; 

(2) the method call is accepted as soon as the current activity is finished, for 
instance, if by the current activity a submethod call is issued; 

(3) the method call is accepted only if the currently executed method call is 
completely finished. 

We do not consider explicit concurrency within an object, i.e. the execution 
of two threads in an object simultaneously. Clearly (1) leads to an execution 
model where any concept of interface abstraction breaks down. Badly enough, 
solution (1) is not far from the concept of concurrent threads in Java where the 
interrupt can be explicitly controlled. Solution (3) is very coarse grain and forces 
to work with rather fine grain method calls. Solution (2) leads to several pending 
threads in objects and thus to a rather scattered execution model. 

In concurrent systems we may also be interested in other patterns of inter- 
action such as those given in Figs. 4 and 5. 




Fig. 4. Communication cascade for a pipeline 



Figure 4 shows the fundamental interaction pattern of pipeline communication. 
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Fig. 5. Coordination by message exchange 



There are two fundamental paradigms in programming: stacks and queues. Stacks 
are the fundamental idea of sequential programming while queues are the fun- 
damental concept of distributed concurrent programming. Method calls are es- 
sentially based on the stack paradigm, which is not appropriate for distributed 
concurrent systems such as the Internet. There we need a concept based on the 
queue paradigm (see [Dahl, Owe 91]). 



4.4 Software Architectures and Component Concept 

The dominant concept in object-orientation is that of a class. From a method- 
ological point of view the notion of a module or a component has to fulfill certain 
principles in the development of large software systems such as 

— hierarchical composition/decomposition, 

— interface specification, 

— appropriate scaling up. 

All these three requirements are not sufficiently well addressed and satisfied 
by the class concept in today’s object-oriented programming languages. 



Class Composition In object-orientation there is no explicit operator to com- 
pose several classes into another, composite class. There is no common concept of 
class composition. Note that the idea of multiple inheritance may look similar to 
class composition but it is, in fact, a completely different concept. Consequently 
there is no way in object-orientation to form larger subsystems structured in 
appropriate subunits. This is a serious flaw of object-orientation since a sup- 
port for a hierarchical structuring of systems is badly needed for a programming 
language for large scale software systems. 
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In fact, it is rather surprising that the concept of class composition does not 
exist explicitly in object-orientation. It can and should be introduced into object- 
orientation without much overhead. The idea of an assembly of new classes by 
instantiations of old classes does not lead to a transparent structure. 

Component Concept and Interfaces One of the severe drawbacks of object- 
orientation is a missing notion of component complementary to that of a class. 
Classes are certainly a too small, too fine grained concept. They rather are imple- 
mentation units (such as modules) and therefore not appropriate for structuring 
large scale systems. 

In fact, component notions are a prerequisite for software architectures. Com- 
ponents are larger grain units that should be hierarchically composable (again) 
from several components. 



Software Architecture For the design of large software systems the notion of 
a software architecture is decisive. A software architecture is the structuring of a 
software system into components and their principles and forms of co-operation 
and interaction. 

For small software systems, classes may be appropriate to form the structure 
of the software architecture. For large systems, however, in object-orientation we 
find hundreds or even thousands of classes. Then classes cannot be any longer 
the appropriate basis and level of granularity for a software architecture. 

5 Concluding Remarks 

Are we able to create an approach to software system design and to programming 
that does not show the weaknesses of object-orientation of today and neverthe- 
less still manages to maintain most of its advantages? We think yes! There are 
approaches to the programming of distributed systems based on state machines 
(such as statecharts) that support asynchronous models of concurrent execution. 
An interesting approach in that direction is ROOM (see [Room 94]) that in a 
very consequent way introduces the required techniques. 

A generalization of this model along the lines of Focus (see [Broy 98]) and 
the prototype CASE tool AutoFocus (see [AutoFocus 00]) shows many of the 
features described above. The introduction of the classical concepts of object- 
orientation into this model is an interesting exercise. 

Ole-Johan Dahl in his original work was much closer to the idea of concurrent 
distributed systems as most of the so — called object — oriented programming 
languages of today. 
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Abstract. This paper studies the composition of modules that can hide 
information, over a very general class of logical systems called inclusive 
institutions. Two semantics are given for the composition of such modules 
using hve familiar operations, and a property called conservativity is 
shown necessary and sufficient for these semantics to agree. The first 
semantics extracts the visible properties of the result of composing both 
the visible and hidden parts of modules, while the second uses only the 
visible properties of the components; the two semantics agree when the 
visible consequences of hidden information are enough to determine the 
result of the composition. A number of “laws of software composition” 
are proved relating the five composition operations. Inclusive institutions 
simplify many of the proofs. The approach has application to module 
composition technology, for both programs and specifications. 



1 Introduction 

Modularization reduces the complexity of large systems by breaking them into 
more comprehensible parts; this eases both initial construction and later modi- 
fication, and it also facilitates reuse. Parameterized programming^ significantly 
further enhances flexibility and reusability of modules, by providing parameter- 
ized modules along with views, also called fitting morphisms, which say how to fit 
the syntax of a formal parameter to an actual parameter in a convenient, flexible 
way, including defaults when there is only one reasonable choice; moreover, views 
can be parameterized, dependent types are supported through formal parameters 
that are parameterized by previously introduced formal parameters, and module 
expressions compose modules into systems [18,19]. We use essentially the same 
module composition operations as in the original Glear language [7], for aggre- 
gating, renaming, enriching, hiding, and instantiating parameterized modules. 
Module expressions are terms built from basic modules, parameterized modules, 
and views, using these five operations; we believe that making views first class 
citizens is key to realizing the full practical potential of modularization. 

® As in [18,19], this term should be understood as applying to both specifications and 
programs, as well as to their combination. 
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The approach of this paper is by no means limited to specification languages, 
let alone to equational specification languages. In particular, the lileanna sys- 
tem has significantly extended the power and the efficiency of Ada generics 
by applying these ideas; lileanna module expressions are “executed” by com- 
bining the code in their modules, resulting in optimized, executable programs 
[42,26]. LILEANNA has been used in industry to build navigation system software 
for helicopters, and the original Clear and OBJ languages inspired aspects of 
parameterization in the module systems of Ada, ML, and C-I--I-. 

There are many good reasons to hide information in modules. First, following 
Parnas [34], information hiding supports data abstraction, and more practically, 
allows replacing one module by another having the same semantics for its vis- 
ible signature, but a different implementation, without having to worry that 
other modules might have used details of the implementation. Second, a classic 
result of Bergstra and Tucker [3] says that every computable algebra has a fi- 
nite equational specification with some hidden operations, and examples show 
that the hidden operations are sometimes necessary (see [32] for a survey of this 
area). Third, [23] shows that every [finite] behavioral (also called observational, 
or hidden) algebraic specification [20,22,38,35] has an equivalent [finite] informa- 
tion hiding specification with the same models, but using ordinary satisfaction. 
However, the translation of finite behavioral specifications to hidden informa- 
tion modules in [23] does not explain context induction [28] , and hence does not 
support behavioral proofs by induction. To overcome this, [36] gave an improved 
translation, that takes account of experiments and their recursive evaluation 
in a bottom-up fashion. This new translation justifies behavioral proofs by in- 
duction, even though neither induction nor equational reasoning are in general 
sound for behavioral equivalence. Some of the same ideas seem to have more 
recently appeared in [5], using a different notation. 

Category theory and institutions are heavily used in this paper. Institutions 
(see Section 2.3) formalize the informal notion of logical system, with a balanced 
interplay of syntax and semantics, to support research that is independent of the 
underlying logic. An institution consists of: a category of signatures; a functor 
from signatures S to classes of A-sentences; a contravariant functor from sig- 
natures S to categories of A-models; and for every signature A, a relation of 
satisfaction \=s between A-sentences and A-models, such that M' \=s' ¥’(/) iff 
(p(M') \=z: /, for every signature morphism ip: S ^ S', every Abmodel M' , 
and every A-sentence /, where p>{f) is the translation of / according to p and 
cp(M') is the reduct of M according to (p. Given a class A of A-sentences, let 
A* denote the class of A-models that satisfy every sentence in A, and given a 
class V of A-models, let V* denote the class of A-sentences that are satisfied by 
all models in V. Modularization has been one of the most important applications 
of institutions. Many logical systems have been shown to be institutions, and 
most recent algebraic specification languages have an institution-based seman- 
tics, e.g., CAST [9], CafeOBJ [14], OBJ3 [27], and BOBJ [25]. Other applications 
include translating between logics (see [24] for a survey), and database integra- 
tion using meta-data expressed as theories in a suitable institution [1] (this work 
actually has further ambitions to meta-data management and integration for 
any kind of data [4]). 
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Defining and proving properties of module systems can be greatly simplified 
when the institution involved is inclusive, in the sense that its category of signa- 
tures satisfies certain natural conditions that axiomatize the notion of inclusion. 
(Our inclusive institutions are simpler than the original ones in [15] because we 
use the inclusive categories of [24]; see Section 2.2.) It appears that all institu- 
tions proposed for specification or programming are inclusive. Many properties 
of inclusive institutions are proved here, including a generalization of the Closure 
Lemma of classical institution theory. 

Let I be a fixed inclusive institution. In this paper, we let the term module 
refer to a triple {<P, S, A) where is a subsignature of S, and A is a set of S- 
sentences, all from 2. S is called the working signature, and it includes both the 
public and the private operations of the module; 2> is called the visible signature, 
which defines the public interface; elements of A are called axioms. The visible 
theorems of M = (^, E, A), denoted Vth{M), are the ^-sentences in the “double 
star closure” A** of A. A model of M is a ^-model satisfying all its visible 
theorems. A transparent module has 2> = E-, these correspond to specifications 
without information hiding. 

In the first semantics, the meaning of a module expression is the visible 
theory of the result of evaluating the module expression compositionally (i.e., 
recursively) over the five operations. For example, if M = (<P, E, A) then |M]j^ = 
Vth{M), and given also M' = (<!>', E' , A), then |M + M'j^ = Vth{<P U A U 
E',A\J A). This semantics is the same as that in [26], except that signature 
union comes from inclusive categories rather than the extended set theory used 
in [26] . In the second semantics, following [37] , meaning is directly compositional 
over visible theories. As before, |M ]2 = Vth{M), but now |M -|- M ']2 = (|M] 2 U 
|M'] 2 )**, where this closure is relative to the signature <PU<P'. Meanings in this 
semantics for the other module composition operations are similar, and do not 
use the hidden parts of component modules. Semantics similar to these have 
been given in the tradition of [39], but are defined as classes of models rather 
than as theories. 

The first semantics is more comprehensive because it uses more information; 
it is a non-trivial theorem that the two semantics agree when all modules involved 
are conservative, where a module (^, E, A) is conservative iff every ^-model of 
its visible theorems can be extended to a A-model of A. Transparent modules are 
obviously conservative, but in general, testing for conservativity depends on the 
institution involved, and can be difficult. The modules that arise in practice for 
equational institutions are conservative. One approach for showing conservativity 
in equational institutions is to show that every <P-algebra can be enriched with 
hidden carriers and operations, such that it satisfies the axioms. Since each 
semantics gives a theory, each has an associated class of models, and these two 
classes also agree under conservativity. Example 2 shows that conservativity is 
necessary as well as sufficient, even for the equational institution. 

This paper also proves a number of identities that hold among the meanings 
of simple module expressions. These can be considered “basic laws of software 
engineering” (though they are mostly very simple); such laws are used in the 
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LILEANNA System [42,26] to simplify module expressions before handing them 
over to the backend of the Ada compiler for optimization, and result in more 
efficient code than composing the same system in raw Ada. Example laws are 
E + E' = E' + E and E + {E' + E”) = {E + E') + E", where E = E' indicates 
that = |A']^ for module expressions E, E' . Of course, these are very simple 
examples, the most interesting identities involve instantiation of parameterized 
modules. We have found that inclusive institutions significantly simplify the 
proofs of such laws. 

1.1 Related Work 

We mainly discuss work that directly influenced this paper; readers wanting 
more background or historical information should consult references in the cited 
papers. The most influential works for us were [26] and [15]. Many results of the 
present paper appear in a slightly more concrete form in [26], which considered 
the same module system as this paper, using a version of institutions in which 
signatures are structured set/tuple hierarchies, so that inclusions are directly 
available and need not be axiomatized. This approach is less general than that 
of the present paper‘d, but has the advantage of making the techniques for im- 
plementing the module system more explicit. On the other hand, proofs are less 
elegant, and more difficult to discover, and the present paper supplies proofs 
that are missing from [26] . 

Modularization over inclusive institutions is studied in [15], but its modules 
do not hide information, and its notion of inclusion system is less general then the 
present one. [2] axiomatizes operations on modules and proves certain properties, 
including a normalization theorem; unfortunately, first order logic is built into 
their formalism for sentences, which limits the application of their results. When 
the institution is first order logic, the results in this paper prove from more basic 
principles all of the axioms in [2] that concern our operations. 

Generalizing prior work of Cengarle for first order logic [8], Borzyszkowski 
[6] gives a nice proof that under certain sufficient conditions (semantic forms 
of amalgamation and interpolation are the main ones) the two semantics agree; 
however, [6] does not treat parameterized modules, uses a different notation in 
which one semantics is formulated as a deductive system, and uses a different 
notion of institution that seems unnecessarily complex. Since the assumptions of 
the present paper are necessary and sufficient, it would be interesting to see how 
they relate to those of [6] , despite the different notions of institution employed; 
the relation between interpolation and conservativity seems worthy of further 
investigation. 

Inclusive institutions seem an attractive alternative to approaches like “insti- 
tutions with symbols” [33], which assign sets of symbols to signatures, because 
inclusions automatically keep track of shared symbols in subsignatures, while 
allowing the usual operations on modules to be easily and naturally expressed; 
the approach of [33] was developed for the semantics of the European CASE 

Although it seems to include all the standard examples. 
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[9] specification language. Diaconescu [12] studies modules without information 
hiding for equational-like logics, using category-based equational logic (CBEL). 
We believe that under some mild conditions, CBEL is an inclusive institution, 
so that results in this paper would apply. 

In contrast® to [40,39], it is our view that parameterized programs can be 
considered parameterized theories, by using an appropriate institution, having 
programs as sentences and executions as models (though it would of course be a 
substantial task to write out all the details of such an institution, e.g., for the C 
language). We also disagree with the view expressed forcefully in [40,39] that it is 
necessary to hybridize algebraic specification with type theory in order to address 
concerns that blend specification and programming. In particular, we disagree 
with their claim that colimits are not adequate for parameterized programs, 
which should instead be treated using dependent types. Indeed, lileanna, which 
is an implemented programming and specification system based on the same ap- 
proach as this paper, shows that this claim is false [42,26]. lileanna module 
expressions tell the system how to combine the Ada intermediate compiled code 
for components, which is then passed to the compiler backend, resulting in ef- 
ficient executable composed programs. The Specware system takes a somewhat 
different approach to generating code, but still uses colimits for composition 
[30] . The existence of institutions with programs as sentences explains why col- 
imit constructions work for module composition at the code level, not just at 
the specification level. Some confusion perhaps arises because of the familiarity 
of institutions from mathematical logic, such as the lambda calculus and equa- 
tional logic, which have been applied to certain classes of functional programs. 
Moreover, the relation between the Ada programs and the Anna specifications 
of LILEANNA is given by an institution of this more traditional kind. 

Section 2 of this paper reviews notation and concepts from category theory, 
inclusive categories and institutions, while inclusive institutions are presented in 
Section 3, and Section 4 introduces modules. Section 5 is the heart of the paper, 
giving the five module operations with their semantics and the basic laws, while 
Section 6 gives some conclusions and future directions. We consider this paper 
a natural next step in the research on parameterized programming begun in 
[18,19] for the OBJ specification and term rewriting language [27], inspired by 
the Clear module system [7], and further developed in [26] and [15]. 

2 Preliminaries 

Categories, inclusions and institutions are heavily used in this paper, and this 
section briefly introduces our notation and terminology for these concepts. 



® This paragraph and some related footnotes were written reluctantly, at the request 
of a referee, and many details are omitted, because we feel that such discussions tend 
to distract from technical content. 
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2.1 Categories 

The reader is assumed to be familiar with basics of category theory, including 
limits, colimits, functors, and adjoints [31,29]. jCj denotes the class of objects 
of a category C, and C{A, B) denotes the set of morphisms in C from object A 
to object B. The composition of morphisms is written in diagrammatic order, 
that is, f;g: A ^ C is the composition of / : A ^ B with g: B ^ C. Let 
Cat denote the (quasi-)category with locally small categories as objects and 
with functors as morphisms. A family of morphisms {cj : Ai B \ i G 1} is 
epimorphic iff for any two morphisms f,g: B ^ C, ii ei] f = ei\g for each 
i G / then f = g. 

A functor T \ C ^ T> is full (faithful) if its restrictions IF: C{A,B) 
'D{T{A),T{B)) are surjective (injective) for all objects A,B in C. T is dense 
provided that for each D G \T>\ there is some C G jCj such that T{C) is isomor- 
phic to D. A full subcategory is a subcategory such that the inclusion functor 
is full. A category is skeletal iff isomorphic objects are identical. A skeleton of 
a category C is a maximal full skeletal subcategory of C; it can be shown that any 
two skeletons of a category are isomorphic in Cat. A category C is equivalent 
to a category I? iff C and T> have isomorphic skeletons. It is known [31] that two 
categories C and T> are equivalent iff there exists a functor T \ C ^ V which is 
full, faithful and dense. 

Pullbacks in Cat have the following special property: if a pair of functors 
Ti'. V ^ Cl and IF 2 : V ^ C 2 is a, pullback in Cat oi Q\-. C\ ^ V and 
Gi' C 2 ^ V, and if Ci G \C\\ and C 2 G IC 2 I are such that Gi{Ci) = ^ 2 (^ 2 ), then 
there is a unique object P in V such that iFi{P) = C\ and ip 2 {P) = C 2 . 

2.2 Inclusive Categories 

Many categories have certain morphisms which are intuitively inclusions. The 
problem of characterizing such morphisms was raised in [21], first solved in [15] 
with the notion of inclusion system, and further developed and simplified in 
[10,11,37,24]. The simplest version occurs in [24]: An inclusive category C is 
a category having a broad subcategory® X which is a poclass (i.e., its objects are 
a class such that each I{A, B) has at most one element, and if both I{A, B) and 
X{B, A) are non-empty, then A= B) with finite products and coproducts, called 
intersection (denoted n) and union (denoted U or possibly -I-), respectively, 
such that for every pair A, B of objects, A U i? is a pushout of A n i? in C; 
morphisms in X are written ^ and called inclusions. In particular, C and 
X have an initial object, which we denote 0, and Ai,...,A„ are disjoint iff 
Ai n Aj = 0 for i j. C is distributive iff X is distributive, in the sense that 
A U (B n C) = (A U B) n (A U C) (which, as in lattice theory, is equivalent to 
A n (B U C) = (A n B) U (A n C)) in X. 



In the sense that it has the same objects as C. 
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Proposition 1. In any inclusive category C: 

1. The family of inclusions Ai Uj=i * = 1, n is epimorphic. 

is a colimit in C of the diagram given by the pairs of inclusions 

Ai n Aj ^ Ai and Ai n Aj ^ Aj for i,j = 1, n. 

The proof is elementary and fun, but a bit tedious. We leave its proof as an 
exercise for the tenacious reader, emphasizing that distributivity of C is indeed 
not necessary. 

We say that morphisms hi: Ai ^ Bi in C for i = have a union, 

written Uj=i there is a morphism h-. ^ Uj=i ^3 such that 

{Ai ^ [Sj=\Aj)-, h = hi; {Bi ^ Uj=i^i) * = 1; Such a morphism h is 
unique if it exists, and h\, ..., /i„ have a union whenever A\, ..., An are disjoint. 
C has pushouts which preserve inclusions iff for any pair of arrows {A ^ 
B,A ^ A') there are pushouts of the form {A' ^ B',B B'). A functor 
between two inclusive categories is inclusive (or preserves inclusions) iff it 
takes inclusions in the source category to inclusions in the target category. 

2.3 Institutions 

Institutions were introduced by Goguen and Burstall [21] to formalize the intu- 
itive notion of logical system. An institution consists of a category Sign whose 
objects are called signatures, a functor Sen : Sign — > Set giving for each sig- 
nature a set whose elements are called A-sentences, a functor Mod : Sign ^ 
Cat'^^ giving for each signature A a category of A-models, and a signature- 
indexed relation called satisfaction, \= = {^i;| A G Sign}, where ^ 
|Mod(A)| X Sen(A), such that for each signature morphism h: S ^ A', the 
satisfaction condition, m' \=s' Sen(ft,)(a) iff Mod(ft,)(m') \=s a, holds for 
all m' G |Mod(A')| and a G Sen(A). We may write h for Sen{h) and _[/j for 
Mod(/i); m\h is called the /i-reduct of m. The satisfaction condition then takes 
the simpler form m' \=s' h{a) iff m'\h \=i: a. We may omit the subscript A 
when it can be inferred from context. Given a set A of A-sentences, let 

A* = {m G Mod(A) | m a for all a G A} , 
and given a class V of A-models, let 

V* = {a G Sen(A) | m \=jj a for all m G A} . 

Then the closure of a set of A-sentences A is A* = A**, and _* is a closure 
operator, i.e., it is extensive, monotonic and idempotent; the sentences in A* are 
called the theorems of A. 

A specification or presentation is a pair (A, A) where A is a signature and 
A is a set of A-sentences. A specification morphism from (A, A) to (A', A') 
is a signature morphism h: S ^ S' such that h{A) C A". Specifications and 
specification morphisms form a category denoted Spec. A theory (A, A) is a 
specification with A = A*; the full subcategory of theories in Spec is denoted 
Th. Given a specification (A, A), Mod(A, A) denotes the full subcategory of 
Mod(A) of models that satisfy A; given a morphism h: (A, A) ^ (A', A'), 
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_ takes models of A! to models of A. We will also write A B when 
Mod(Z',A) C Mod(Z', _B). Th and Spec are equivalent categories, where the 
equivalence functor is just the inclusion U : Th ^ Spec. This functor has a 
left-adjoint-left-inverse T : Spec — > Th, given by A) = {B, A*) on objects 
and the identity on morphisms; note that T is also right adjoint to hi, so that 
Th is a reflective and coreflective subcategory of Spec. 

A theory morphism h : (A, A) {S' , A) is conservative iff for any (A, A)- 

model m there is a (A', A')-model in' such that m! \h= m, i.e., iff its retract 
map _ f/i : Mod(A’', A') ^ Mod(A’, A) is surjective. A signature morphism 
h: B ^ S' is conservative iff it is conservative as a morphism of void theories, 

i.e., iff h: {B,tj)*) (A', 0 '*) is conservative. An important result of [ 21 ] is that 

Th has whatever colimits Sign has; in particular, Th has pushouts whenever 
Sign does, and if hi : {B, A) ^ (Ai, Ai) and /12 : (A, A) ^ (A2, A2) are theory 
morphisms, and if {h'l : Ai ^ A', h'2 ■ A2 ^ A') is a pushout of (/ii,/i2) in 
Sign, then (/I'l : (Ai,Ai) ^ (A', A'), h'2' (A2,A2) ^ (A', A')) is a pushout 
of hi,h2 in Th, where A = (/i'i(Ai) U h' 2{A2)Y ■ Moreover, 

Proposition 2. Given h: B ^ A', A, A C Sen(A), and a G Sen(A), then: 

1 . Closure Lemma: h{A*) C h{A)* , i.e., A \=z: a implies h{A) \=zj' h{a). 

2 . If h is eonservative, then A \=s a iff h{A) \=zj' h{a). 

3 . h{A*Y = h{A)\ 

I (A* U A')* = (AU A')V 

If any reader is disturbed by the size of the categories involved in the no- 
tion of institution, it may be reassuring that, for the purposes of this paper at 
least, little is lost by restricting categories of signatures to be small categories. 
Indeed, if signatures are finite constructions using symbols drawn from a fixed 
countable set, as is usual in computer science, then we could even assume that 
signature categories have only a countable number of objects. Similar restric- 
tions could be given for the values of the sentence and model functors; although 
this entails weaker completeness properties, the practical applications to module 
composition only require finite colimits of theories. 

3 Inclusive Institutions 

The semantics of module systems over an institution is much simplified when 
signature inclusions are available, in the following sense: 

Definition 1. An institution is inclusive ijf Sign is inelusive and has pushouts 
which preserve inclusions, Sen is inclusive, and Mod preserves pushouts which 
preserve inclusions, i.e., takes them to pullbacks in Cat. An inclusive institution 
is distributive iff its category of signatures is distributive. 

We now fix an inclusive institution and refer to it as the “given institution.” 
Many natural properties can be expressed intuitively in inclusive institutions, 
for example, if A and A are sets of A- and A'-sentences, respectively, then 
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(A*U A'*)* = {A^JA'Y, where the outermost closures are over Z'U i7'-sentences; 
also, if ^ ^ 17, a G Sen(^), and A C Sen(<?), then A |=<|> a implies A a, 
with equivalence when ^ ^ U is conservative. The category Th tends to have 
the same properties as Sign. In particular, 

Proposition 3. For any inclusive institution, Th is inclusive and has pushouts 
that preserve inclusions, where the inclusions iTh in Th are morphisms (S,A) ^ 
{S', A') where S ^ S' is an inclusion in Sign and AQ A' . 

Proof: It is easy to check that Xxh is a poclass with the same objects as Th. 

Define the union of theories {S, A), (S', A') by (S, A) U (S', A') = (SU S', (TU 
A'Y) where the closure is over (T’UT'^)-sentences, and define their intersection by 
(S, A)n(S' , A) = (SnS' , AnA). We now show correctness of these definitions. 
That union is a pushout of an intersection in Xph follows from the construction 
of pushouts in Th. Now consider an inclusion (S,A) ^ (Si,Ai) in Th and a 
morphism h: (S,A) (S2,A2) in Th. Let (S2 S',hs>'. Si S') be a 

pushout of (S ^ Si,h\ L7 — > S2) in Sign which preserves the inclusion. Then 
((S2,A2) ^ (S' , A),hs> ■ (Si,Ai) (S' ,A)) is the desired pushout in Th, 

where A = (A2 U hs'(^i)Y ^ again by the construction of pushouts in Th. □ 



Convention 1 We do not assume any particular way to calculate pushouts of 
signatures, nor do we require these pushouts to have any special properties, but 
for notational convenience, we assume fixed pushouts that preserve the inclu- 
sions; let (<l>' ^ Sh, hs-S^ Sh) denote this pushout for ^ T", h: ^ 

<P'). We say that a choice of such pushouts is closed under horizontal and/or 
vertical composition iff for any (F ^ S, h: — > <P'), = S'^ and 

S ^ S' and/or iff (Sh)g = S^-g for any signature morphism g with source <P' . 
Also, we may say theory extension for theory inclusion. 

Open Problem It would be useful to have an algorithm for pushouts of the 
usual signatures, that is closed under horizontal and/or vertical composition, 
i.e., such that ^[h^) ~ ^'h any (<F ^ S, h: <F ^ <F') and S ^ S' , and such 
that (Sh)g = Sh;g for any signature morphism g with source <F' . 

Definition 2. Given i: <P ^ S in Sign and A C Sen(A), let Th^(A) denote 
i~^(A*) C Sen(^), called the (^-visible theorems of A (over S). 

Th^(A) contains all the (^-sentences that are consequences of A. When i is an 
identity, then Th^(A) = A*. 

Example 1 Assume a logic where equational reasoning and induction are sound, 
and let LIST be a specification of lists containing at least the sorts Elt and List, 
a constant nil of sort List, and a constructor cons : Elt x List List. Let 
extend this signature by a reverse operation rev : List List, let S extend 
by a private operation aux : List x List List, and let A contain the equations 
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(VL : List) rev{L) = aux{L,nil). 

(VP : List) aux{nil,P) = P. 

(VP : Elt\ L, P : List) aux{cons{E, L), P) = aux{L, cons{E, P)). 

Then the following are two visible theorems of A over E: 

rev {nil) = nil , 

(VP : List) rev{rev{L)) = L . 

The proof of the second requires induction and two lemmas. □ 

The following properties are familiar for many particular logics, because they 
hold in any inclusive institution: 

Proposition 4. LfE^fL^E, AC A' C Sen(P), and B C Sen(<?), then: 

1. BC Th^{B). 

2. Tht{B) C Th§{B). 

3. Th%{B) = Th§{B) if <l> ^ E is conservative. 

I Th^{A) C Thf{A). 

5. Th^{A) C Th^{A'). 

6. Th^{A) C Thf{Th^{A)). 

7. Th^{Th^{A)) C Th^{A). 

8. Thf{Th§{A)) = Thf{A). 

9. Th%{Th^{A)) = Thf{A). 

10. Th%{Th^{A))=Th^{A). 

Proof: Let i' \ ^ and i: <l> ^ E he the two inclusions. 

1. lib & B then B \=s b, i.e., b S Th^{B). 

2. By 1. of Proposition 2. 

3. This is exactly 2. in Proposition 2. 

4. Since Sen is a morphism of inclusion systems, a is in Sen{(p) whenever a is 
in Sen(tp). 

5. This is equivalent to i~^{A*) C i~^{A'*), which holds because A* C A'* . 

6. This follows from 1. with Th^{A) for B. 

7. This is equivalent to {i']i)~^{i~^{A*)) C {i'-,i)~^{A*), which is true because 
i~^{A') C A*. 

8. This follows from 6. and 7., with E = <L. 

9. By 1., Th^{A) C Th%{Th^{A)). On the other hand, Th%{Th^{A)) C 
Th§{Th§{A)) by 2., and also Th%{Th§{A)) C Th§{A) by 8. 

10. This is equivalent to i'~^{i~^{A*)) = {%' ]i)~^{A*), which is true. 

□ 
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Lemma 1 . Generalized Closure Lemma: Given A C Sen(L'), inclusions 
i\ ^ S, i' : <l>' ^ S' , and morphisms h: 4> ^ 4>' and g: E ^ S' such that 



S' 

I 

commutes, then h{Th^{A)) C Th^, (g{A)). 

Proof: Let a be a (^-sentence in Th^{A), so that A \=^ a. Then g{A) \=zj' g{a) 
by the classic Closure Lemma (1. of Proposition 2). But g{a) = h{a) because 
Sen preserves inclusions, and so h{a) is in Th^, (g(A)). □ 



The classic Closure Lemma is the special case of the above where i, i' are iden- 
tities, that is, where nothing is hidden. 



4 Modules 

Our modules, like those in [26], extend the usual algebraic specifications by 
allowing them to hide some information, which however may be used in defining 
their visible features. 

Definition 3 . A module is a triple {<P, S, A), where <l> ^ S are signatures and 
A is a set of E -sentences; is called the visible signature, S the working 

signature, Th{M) = Th%{A) the working theorems, and Vth{M) = Th§{A) 
the visible theorems. A morphism h: M ^ M' of modules is a morphism 
of their visible signatures such that h{Vth{M)) C Vth(M'). 

Modules together with module morphisms form a category MSpec. The func- 
tor A4 from Th to MSpec defined by A4(E,A) = {S,E,A) and M{h) = h, 
is full, faithful and dense, i.e., is an equivalence of categories. Further (by The- 
orem 1, page 91 of [31]), M is part of an adjoint equivalence, with left ad- 
joint T: MSpec ^ Th defined by T{(1>,E,A) = {(l>,Thf{A)) on objects, 
and the identity on morphisms; the unit of this adjunction is 1^ : (^, S, A) —>■ 
Th^{A)). We let U : MSpec ^ MSpec denote the functor T;M, tak- 
ing modules (<?, S,A) to modules Th^{A)). Notice that T is also a right 

adjoint of AJ, so that Th is (modulo isomorphism) a reflective and corefiective 
subcategory of MSpec. Since the two categories are equivalent, every categor- 
ical property [29] of Th is also a property of MSpec. In particular, pushouts 
are preserved and reflected by AJ and T, and MSpec is cocomplete whenever 
Sign is cocomplete, since Th is cocomplete (by [21]). 

Definition 4. A <l>-model m satisfies M = {<P, S, A) iff m \= 4 , Vth{M); in this 
case, we write m ]= M. 

If ft, : M ^ M' is a module morphism and m' ^ M' , then m'\h H Therefore 
in any inclusive institution, the functor Mod extends to MSpec by mapping 
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a module M to the full subcategory Mod(M) of Mod(^) with the (^-models 
satisfying M as its objects. 

It is common to call a theory extension {S, A) ^ {S, A) conservative when 
A = A Sen(if); we call this notion syntactic conservativity to distinguish 
it from the semantic version. Notice that for any module M = {<!>, S, A), the the- 
ory inclusion Vth{M)) ^ {S, Th{M)) is syntactically conservative, because 
Vth{M) = Th^{A) = {a € Sen(^) | A \=s a} = {a G Sen(<P) | a € Th(M)} = 
Th{M) n Sen(<?). As shown in [15], syntactic conservativity is a necessary but 
insufficient condition for semantic conservativity. So it is not surprising that we 
also need a stronger conservativity for modules: 

Definition 5. A module M is conservative if and only if the theory inclusion 
{<P, Vth{M)) ^ (A, Th{M)) is conservative. 

Transparent modules, with d> = S, are always conservative. But there are sim- 
ple non-conservative modules, even for unsorted equational logic, such as the 
following (after [15]): 

Example 2 Let ^ contain a constant a and a unary operation — , let A addi- 
tionally contain a constant c, and let A contain the equation c = — c. Then the 
visible theorems of this module form an empty theory, but there are ^-models 
that cannot be extended to A-models satisfying A, such as m = {1,-1} with 
Wa = 1, m_(l) = —1 and m_(— 1) = 1. □ 

5 Module Composition Operations 

We give two semantics and a definition, for five module composition operations 
from original Clear paper [7], over any inclusive institution. These are functions 
defined on module expressions, i.e., terms involving basic modules, parameter- 
ized modules, and the five operations. The definition follows [26], and is module 
valued, saying what must be implemented, e.g., in lileanna, is denoted \E\ 
where if is a module expression. The first semantics (also from [26]), denoted 
|if]j^, takes the visible theorems of the combined module, while the second se- 
mantics (from [37]), denoted |if] 2 , combines the visible theorems of the com- 
ponent modules. Thus the first semantics uses the definitions of the module 
combination operations, including renamings to avoid name conflicts, while the 
second semantics directly combines their visible theorems. The first semantics 
is more comprehensive because it makes use of more information, and the two 
agree only under special conditions, when interactions among hidden informa- 
tion can safely be ignored. A major result is that conservativity is a necessary 
and sufficient condition for the two semantics to agree; this characterizes when 
it is safe to ignore interactions among hidden parts. All five module operations 
preserve conservativity under natural conditions. When proving theorems about 
composed systems, it is often easier to use hidden information than to use only 
its consequences; for example, the former may be finite while the latter is infinite. 
Therefore a theorem prover should have access to all of the hidden information, 
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e.g., the combined module given by the definitions, or the module expression 
itself, which provides additional structuring information. 

5.1 Aggregation 

The aggregation of modules is essentially the componentwise union of their parts. 
However, this simple view is complicated by the need to handle symbols hav- 
ing the same name but defined in different modules, and symbols coming from 
shared submodules. A standard way to prevent such name clashes is to tag sym- 
bols with the name of the module where they are defined; symbols defined in 
shared submodules are then tagged just once. Some languages with overloaded 
operators have complex symbol resolution algorithms, while others take the sim- 
ple union of all symbols, leaving the name collision problem to the user. The 
latter approach is actually quite appropriate for investigating the role of hid- 
den symbols in the semantics of aggregation, and of module composition more 
generally. Moreover, if symbols are already tagged with their originating mod- 
ule when they are declared, with their untagged name available as a convenient 
abbreviation when it is unambiguous (as is done in implementations of the OBJ 
systems [27,25]), then this approach is actually equivalent to the standard one. 

We will show that the two semantics for aggregation agree when the compo- 
nent modules are conservative and all the symbols that they share are visible, 
and we will give counterexamples showing that both of these requirements are 
necessary. We will also give some simple “laws of software composition” for ag- 
gregation, and prove some other basic properties of aggregation. 

Definition 6. Given modules M = {<P,S,A) and M' = (<?', 27', A'), their ag- 
gregation is defined to be 27U27', AU A'), or more formally, |M-|-M'| = 

{<p\j<p' ,E\JS',A\JA'). Moreover, we let {M + M'j^ = Vth{<PU<P' , SUE' , AuA'), 
and |M + = (Vth{M) U Vth{M'))* , where the closure is with respect to 

This makes sense because (PUd)' ^ 27U27' and AuA' is a set of (27U27')-sentences, 
since Sen preserves inclusions. Because M + M' is a formal expression, it is an 
abuse of notation to write M + M' = {d>\J <P' ,E \J 27', A U A'), but it is often 
convenient, and we will use this convention for the other module combination 
operations, as well as for aggregation. In particular, we may write E = M for 
the more precise |i7| = M where i7 is a module expression and M is a module. 
Note that |M| = M, and that"^ here and hereafter, |M]j^ = Vth{\M\). Since each 
of the three formal semantic definitions extends recursively over the module 
combination operations to all module expressions, it also makes sense to write 
E = E' for |i7| = |i7'| where E, E' are both module expressions, as is (implicitly) 
done in the following: 

Fact 1 Aggregation is commutative, associative and idempotent. 

^ For some reason, the expression Vth(E') where E' — \E\ is called the normal form 
of E in the tradition of [40,39,6]. 
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A precise form of the first assertion is |M + M'\ = \M' + M\. The proof of this 
fact uses that union has the three corresponding properties. It also follows that 
\M + = \M' + and that \M + M'\^ = + Af]2- Hereafter, we will 

systematically employ the abuse of notation discussed above. 

Proposition 5. If i and i' denote the inclusions <P ^ and (I' ^ <PU <P' , 

respectively, then i: M ^ M+M' and i ' : M' M+M' are module morphisms. 
Therefore m \= M + M' implies m\,p ^ M and m\,p' ^ M' for any (<? U <P')- 
model m. 

Proof: This is immediate, noting that M + M' denotes the module \M + M'\. 

□ 



The following technically important result informally says that if all common 
symbols of two conservative modules are visible, then any model of both sets of 
visible theorems extends to a model of both sets of working theorems: 

Theorem 1. If modules M = (<I>,S,A) and M' = {<!>', S', A') are conservative 
and if C\ T>' = S C\ S' , then for any {‘I U <P') -model m such that m 
Vth{M) U Vth{M') there is a {S LI S')-model m' such that m' \<p\j<p'= m and 
m' Th{M) U Th(M'). 

Proof: By the Satisfaction Condition, \= 4 , Th^ (A) and m\ 4 ,> 1 =^)' Th^, {A'). 
Since {I>,S,A) and {I>',S',A') are conservative, there exist a A-model ms of 
A and a A'-model ms' of A' such that ms\$= m\<p and ms'\<i’'= m\<p>. 




Then by the functoriality of reducts, ms \$n$'= (Tns\<i>) \$n$'= |'<i>n<f'= 

m|'<fn<g'= ■ Since S L S' = f] T>' , and 

Mod preserves intersection-union pushouts, and by the construction of pullbacks 
in Cat, there is a (unique) (AU A')-model m' such that ms and m'\s'= 

ms'', thus m'ls \=s A and m'\s' \=s' A' . Therefore the Satisfaction Condition 
gives m' \=sus' AL A' . The reader may check that this essentially says that 
m' is a model of both Th{M) and Th{M'), and that |'<g= m\4, and 

m\<i,>. Therefore rn'l^u-p’ satisfies the conditions that are uniquely 
satisfied by m (because the union of ^ and <P' is a pushout of their intersection, 
because Mod preserves it, and because of the way pullbacks are built in Cat). 
Therefore m'\$\j$r= m. □ 
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Proposition 6. If M and M' are modules as in Theorem 1, then 

1. {M + M\ = + 

2. m\= M + M' iff m\$ ^ M and m\^' |= M' for any {<P U <T')-model m. 

3. M + M' is conservative. 

Proof: 1. is equivalent to {A\J A') = ( T/iJ ( A) U T/iJ, (A')). By 

Proposition 4, Th§{A) C Th§^^, {A U B) and Th^, (B) C Th^^^, {A U B), so 
U Th^, (B)) C Th^y^i {AU B). Conversely, consider a 
sentence a such that A\J A' \=sui:' a, and let m be a (^U^')-model for Th^{A) 
and Th§, {A'). By Theorem 1, there exists a (if U if')-model m' oi A \J A' such 
that m' |'^u< 5 '= w. Then m' \=syjs' a, and so by the Satisfaction Condition, 
Q) that is, m Consequently, a is in Th$'^$, (Th^ (A) U 

Th^,'(A')). This shows that Th^^^,' (A U A') C Th$[j$',(Th^(A) U Th^,'(A')). 

2. follows from the equivalences: 



m \= M + M' iff 

w |=<fu< 5 ' Vth{M + M') iff (by 1.) 

m |=<fu<5' (Vth{M) U Vth{M'))* iff 

m |=<j.u<?' Vth{M) U Vth(M') iff 



m |=<fu<?' Vth{M) and m |=<fu<?' Vth(M') iff 
m\,i> \=,p Vth{M) and |=^/ Vth(M') iff 
m\,p \= M and |= M' . 

Only the right to left implication is interesting, since the other direction needs 
neither conservativity nor that n <?' = if C if ' . 

For 3., take a (<? U <P')-model m of Th§fj^, {A U A'). Then m is also a (^ U <!')- 
model of Th^{A) and Th^',{A'), and by Theorem 1 there is a (if U if')-model 
to' of A U A' such that to' r<z>u<f'= m. Therefore, to' is a (if U if')-model of 
Th%\j%'{A U A')\ this shows that (<?, if. A) + (^', if'. A') is conservative. □ 

Despite its somewhat complex proof, this result looks so natural that one might 
be tempted to think its hypothesis too strong. But visibility of shared symbols 
really is needed, as shown by the following: 

Example 3 Let M have a visible constant 0, a hidden constant c and the sen- 
tence 0 = c, while M' has a constant 1, the same hidden c, and the sentence 
1 = c. Then ( Vth{M) U Vth{M'))* is empty while Vth{M + M') contains 0 = 1. 
This suggests that an implementation of aggregation should rename all shared 
private symbols even if they occurred as a consequence of enriching a shared 
module. □ 



Example 4 Conservativity of M and M' is also needed. Let <I> be the signature 
with constants 0, 1 and a binary operation -I-, let if add to ^ a hidden constant 
c, let A have the equation 0 -I- c = 1 -I- c, let If' = <?' = <?, and let A' have the 
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equations (VX) X + X = 0 and (VX, Y, Z) X + {Y + Z) = {X + Y) + Z. Then 
the equation 0 = 1 + 0 is in Vth{M + M') but not in ( Vth{M) U Vth{M'))* , and 
this occurs because M is not conservative. □ 

The two semantics naturally extend to an arbitrary number of modules: 
|A^i + • • • + = Vth{Mi + • • • + Mn)j and |A/i + • • • + Af „]2 = ( U 

... U Vth{Mn)Y , where the closure is over <Pi U ... U We then have 

Corollary 1. If the given institution is distributive and if Mj = {<Pj, Ej, Aj) 
for j = 1, ...,n are conservative such that Ei n Ej = <Pi D <Pj for i,j = 1, ...,n 
with Mi yf Mj, then: 

1. \Mi + • • • + = \Mi + • • • + M„]2 . 

2. m\= Ml + • • • + Mn iff ^ Mj for j = 1, ..., n, where m is a {<Pi U ... U 

<I>n) -model. 

3. Ml + • • • + Mn is conservative. 



5.2 Renaming 

Renaming is straightforward for transparent algebraic specifications: given a 
specification (E,A) and a morphism h: E ^ E', the renaming of (E,A) by h, 
denoted {E, A)-kh, is obtained by renaming each T'-sentence in A, i.e., {E, A)-kh = 
{E' , h{A)). The situation is more complex for modules with hiding, because only 
the visible symbols are renamed, and because renamed symbols could clash with 
private names. These problems are handled abstractly by signature pushouts. 

Definition 7. Given M = E, A) and h: <P ^ <!>' , the renaming of M by 

h, written M-kh, is the module {<!>', Eh, hs{A)) (see Convention 1). Moreover, 
= Vth{<I>f Eh,hs{A)), and |M*ft ,]2 = h{Vth{M))* , where the closure 
is over <!>' . 

The morphism h is first extended to the morphism h^ on the whole working 
signature, and then A is renamed by hs. This is well defined because <P' ^ Eh 
and hs{A) is a set of T'?i-sentences. Notice that h: M ^ M -k h is a module 
morphism by the Generalized Closure Lemma (Lemma 1), so m |= M k h implies 
m\h \= M for any ^/j-model m. 

The next result says that, assuming conservativity, the two semantics coin- 
cide: the visible theorems of a renamed module are exactly those generated by 
the renamed visible theorems of the initial module, i.e., the models of the re- 
named module are exactly those whose reducts are models of the initial module; 
moreover, conservativity is preserved under renaming. 

Proposition 7. If M = {<!>, E, A) is a conservative module, then 

1. {Mkhl, = [Mkh\^ . 

2. m\= M kh iff m\h H ^ -model m. 

3. M kh is conservative. 
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Proof: For 1., we need Th%, {h{Th^ {A))) = Th§!'{hs{A)). Lemma 1 implies 

h{Th^{A))) C Th^!'{hs{A)); applying Th%', to this inclusion, Proposition 4 
gives Th%,{h{Th^{A))) C Thf!'{hs{A)). Conversely, let a G Sen(^') such that 
hs{A) a and let m' be a <P'-model such that m' \=$i h{Th§{A)). We 

need to show m' |=^' a. By the Satisfaction Condition, m'\h \=<p Th^{A). Since 
(^,U,A) is conservative, there is a Li-model m such that m ['^= m' and 
m \=s Th^{A). By the construction of pullbacks in Cat (Section 2.1), and since 
Mod preserves intersection-union pushouts (Definition 1), there is a L7?i-model, 
say mh, such that mh\hE= ™ ^nd mh\<i’'= m' . Then mhlhs \=s A (because 
m \=s Th^{A) and A C Thf;{A)), and so mh \=Sh hs{A). Further, mh \=Sh a 
because hs{A) \=Sh Finally, if i' is the inclusion <P' ^ Sh then mh \=Sh 
so mh\i' \=$' a; therefore m' \=$> a. 

2. follows since \= MiSm\h \=$ Vth{M) iffm \= 4 ,' h{Vth{M)) (Satisfaction 
Condition) iff m \=^> h{Vth{M))* iff m \=,pi Vth{M * h) (by 1.) iff m |= M * h. 

For 3., let m be a <P'-model of Th^!'{hs{A)), that is, m \= M -k h. By 2., m\h is 
a <P-model of Th^{A). Then by conservativity of {(1>,S,A), there is a L7-model 
ms of A such that ms\<i’= m\h- But the pair of morphisms hs and ’P' ^ Sh 
is a pushout of h and <P ^ S; therefore, since Mod preserves these pushouts 
(see Definition 1), by the construction of pullbacks in Cat, there is a Lf/j-model 
m' such that m'\(^hs)= and m'\,pi= m. Then by the Satisfaction Condition, 
m' \=Sh hs{A), that is m' is a Lf/j-model of Thf,'^{hs{A)). Therefore, for a <P'~ 
model m of Vth{M-kh) we have a L7?i-model m' of Th{Mkh) such that m. 

This shows that M k his conservative. □ 

The following shows that conservativity is necessary here: 

Example 5 Consider the unsorted equational logic module M = {<P, S, A) 
where <P contains constants a, b and a binary operation /, S adds one more 
constant c, and A contains the equations f{a,c) = a and f{b,c) = f{a,a); sup- 
pose also that <P' consists of only one constant d and that h takes both a and 
b to d. Then h{Vth{M))* is an empty theory because Vth{M) is empty, while 
Vth(Mkh) contains the equation f{d,d) = d. Notice that M is not conservative. 
□ 



A desirable property of renamings is that they can be composed, in the sense 
that (M k h)kg = Mk{h; g) for any appropriate h and g. This is straightforward 
for transparent specifications, but it can be hard to insure when hiding is allowed 
because of the variety of conventions for renaming hidden symbols to prevent 
name clashes with the visible symbols in the result (this is similar to the variety 
of choices for hs discussed in Convention 1). 

Proposition 8. If pushouts of inclusions in Sign are chosen such that they 
can be composed vertically (in the sense of Convention 1), then {M kh)k g = 
M k {h]g) for any module M = {(P,E,A) and any morphisms h: <P ^ <P' and 

g- <P> ^ (P» 
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Proof: We calculate as follows: 



{{(!>, S , A) -k h) -k g = {<P' hs{A)) kg 

= <?", {Uh)g,g(z;^)i^T's{A))) 
= {<P",S,,,g,{h;g)s{A)) 

= i^,^,A)k{h-,g) 



by Definition 7 
also by Definition 7 
by hypothesis 
again by Definition 7. 



□ 



5.3 Enrichment 

A common way to reuse software and specification is through enrichment, which 
adds functionality to an existing module. For example, lileanna [42] imple- 
ments enrichment by adding a partial signature to the given signature and then 
adding code over the resulting signature. However, it is simpler to use extensions 
of total signatures. 

Definition 8. Given modules M = {<P, E, A) and (<?', S' , A') with d>' and 
E ^ E' , the enrichment of M by (<?', A', A'), written , E' , A'), is 

the module (<?', A', A U A'), and A', A')]^ = Vth{<P' , E' , AU A') and 

A', A')l2 = Vth{^',^' U S,AU Vth{$' U E, E' , A')). 

Both visible {<P') and private {E') symbols can be added, as well as new sentences 
(in A') involving all these symbols. Note that if i is the inclusion ^ <P' then 
i: M ^ , E' , A') is a morphism of modules, so m ^ , E' , A') 

implies m\,p \= M for any ^'-j^odel m. 

The first semantics is straightforward, but the second requires some expla- 
nation. The key is to take a working-in-M perspective, similar to the intuition 
for module enrichment in software engineering, and to consider how the newly 
added features affect the semantics of the current working environment, regarded 
as visible. Since new visible symbols are added to M , those symbols extend the 
working signature to U E, and their effect on the working environment is the 
visible theorems of the module {d>' U E, E' , A'). We first prove the following: 

Lemma 2. In the context of Definition 8, if E ^ I' ^ E' is such that {W, E' , A') 
is conservative, then Th^ (A U A') = T/if(AU Th^ (^0)- 

Proof: Since A C Th^{A U A') and Th^{A') C Th^ (A U A'), it follows by 

Proposition 4 that Th^{A U Th^ (^0) ^ U A'). Conversely, let a be a 

<F-sentence in Th^ (A U A'). In order to prove that a is in Th^{A U Th^ (A')), 
take a <F-model m of A U Th^ (A'). Since {'P,E',A') is conservative, there is 
a A'-model m' of A! such that m! m. But m \=^ A, that is, m'\^ \=>ir 
A; then by the satisfaction condition we get m' \=s> A. Therefore m' \=s> 
A U A', and so m' \=s> a, because we supposed that A U A' \=s' a. Consequently, 
the satisfaction condition implies m'\q, \=^ a, i.e., m \=^ a. Therefore, a is in 
Th%{A\JTh^\A')). □ 
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Proposition 9. In the context of Definition 8, if {’P'U S, S' , A') is conservative 
then 

1 . , 

2. , S' , A') is conservative if U S , AU Vth{<P' U D , E' , A')) is con- 

servative. 

Proof: Replacing Ih hy <P' U E and then taking the (^'-visible theorems of the 

two sides in the equality given by Lemma 2, we get Th^, {AuA') = Th%fi^ {A\J 
Th^,^j^{A')). Equation 1. now follows from the calculation 

E', A')li = Vth{^', E', A U A') 

= Th%{A\jA') 

= Th%y^{A[JThfis{A')) 

= Vth{<P', <P'\JE,A\J Vth{<P' U 27, E' , A')) 

= lM@i<P',E',A')j^ . 

For 2., let m be a ^'-model of Vth{M@{(I>' , E' , A')). Then by Proposition 
4, TO is also a <P'-model of Vth{<P' ,<P' U 27, A U Vth{I>' U 27, 27', A')) and so by 
conservativity, there is a (^' U 27)-model to" of AU Vth{<P' U 27, 27', A') such that 
m”\<pi= TO. Now, since (^' U 27, 27', A') is conservative, there is a 27'-model to' of 
A' such that to'|'^'ui:= w". By the Satisfaction Condition, to' \=s' A, so that 
to' l=j;> AU A' and, of course, TO'f^<= to. □ 

One can enrich an imported module with essentially anything, including in- 
consistent sentences. But an important special case is when no new visible sym- 
bols are added. This is useful when refining an incomplete module that declares 
an interface, or when one wants to further constrain an existing module in order 
to change its intended semantics (for example, adding the equation 10 = 0 to 
the module that specifies integers to get integers modulo 10). 

Corollary 2. If M' = (27, 27', A') is a conservative module, then 

1. Vth{M@{<P,E',A')) = Vth{<P,E,A\J Vth{M')), and 

2. M@{d>,E' , A') is conservative if {‘I, E, AU Vth{M')) is conservative. 

Proof: This follows by Proposition 9, replacing <P' by <P. □ 

Technically, enriching is a special case of aggregation in our approach, because 
, 27', A') = M {<!>', 27', A'). However, the results that were developed for 
aggregation assumed that the aggregated modules did not have common private 
symbols, which fails for enrichment, where all the private symbols of the enriched 
module are available. 



5.4 Hiding 

Hiding information is very natural in our approach; it just restricts visibility to 
a deeper subsignature. 
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Definition 9. If M = E, A) is a module and I' is a subsignature of <P, then 
I'OM is the module (fP^EjA); also = Vth(I', E, A), and |S'DM ]2 = 

Vth{M)). We call □ the information hiding operator. 

Fewer theorems remain visible after an information hiding operation. The term 
“export operator” is used for □ in [2], but we prefer the more explicit term, 
after [15]; this operation is essentially the same as the “derive” operation of 
Clear [7]. If t: \P ^ (p, then i: \PnM — > M is a module morphism, so m \= M 
implies |= iFnM for any model m. The following shows the relationship 
between the visible theorems of POM and the visible theorems of M, that is, a 
relationship between the two semantics, and it also gives a sufficient condition 
under which hiding preserves conservativity. 

Proposition 10. If M = {P, E, A) is a module and P ^ <P is a signature 
inclusion, then 

1. {POM}^ = {POM}^ and 

2. POM is conservative if M and (P,’P, Vth{M)) are conservative. 

Proof: 1. is equivalent to Th^{A)) = Th%{Th^{A)), which is 10. of Propo- 

sition 4. For 2., let m be a iF-model oiTh^(A)). Since Th^{A)) = Th^{Th§ (7l)), 
by the conservativity of (P, P, Th^{A)), there is a <?-model m' oiTh%{Th^{A)) = 
Th^{A) such that m. Then by the conservativity of (P,E,A) there is a 

27-model m" of Th^{A) with m"\,p= m'. Therefore m"\,^= m, and so {P, E,A) 
is conservative. □ 

Although conservativity is not needed to show equivalence of the two se- 
mantics for hiding, it is needed for equivalence of the semantics for the other 
operations. This is why we always give sufficient conditions for conservativity of 
resulting modules. Notice that conservativity of M does not guarantee conserva- 
tivity of POM: for example, for M a transparent module (which is automatically 
conservative) and P such that POM is not conservative, as in Example 4. 

Testing conservativity of a module {P, E, A) can be difficult, and depends on 
the underlying logic. In many sorted equational logics, one can enrich a iF-algebra 
with new carriers for private sorts (in E — P), and with new private operations, 
and then show that the new 27-algebra satisfies A. Of course, the fewer private 
symbols, the easier this is. For this reason, we prefer to reduce showing the 
conservativity of a module with visible signature P and working signature 27, 
to the conservativity of other two modules: one with visible signature P and 
working signature for ^ ^ ^ 27, and the other with visible signature P 
and working signature 27, as in the above proposition. 

5.5 Parameterization 

One of the most effective supports for software reuse is parameterization. Many 
expositions only treat the one parameter case, saying that it generalizes to many 
parameters in an obvious way. Since one of our goals is conditions for the cor- 
rectness of logic-independent algorithms to flatten complex module structures, 
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and since shared features of parameters are important in this, we treat multiple 
parameterization explicitly, and prove that it is a colimit. 

Definition 10. A parameterized module M\ai :: P\, ...,an ■■ Pn] is a set of 

module morphisms aj; ij : Pj M , where M = (^, P, A) and Pj = (<?' , if', Bj) 
for j = 1, ..., n, such that: 

1. aj : <Pj are isomorphisms of signatures, 

2. ij : <Pj ^ (p are inclusions of signatures, and 

3. are disjoint. 

We say that M is parameterized &?/ «i, Pi, are called the inter- 

faces and M the body. Given a parameterized module M[ai :: Pi, :: P„] 
and morphisms hj : Pj Mj with Mj = (jPj, f2j, Aj) for j = l,...,n, the in- 
stantiation of M by hi,...,hn, written M\h\, ...,hn], is the module 

n n 

U {h4>)s{A) U , 

where ft- = [J ftj (see Section 2.2 and Convention 1). 

j=l n 




i=i 



This complex looking definition has a natural interpretation. First, it says that 
parameters have disjoint interface signatures in the parameterized module; this 
condition, called non-shared parameterization in CafeOBJ [14], avoids obvious 
name clashes, and is easily achieved in practice by tagging parameter signa- 
tures with their parameter names. Second, informally speaking, it says that the 
instantiation of a module is computed as follows: 

1. Calculate hi, which gives for each symbol in M belonging to a parameter 
Pi its actual instance symbol; 

2. store all these mappings in a table ft; 

3. Calculate ft’s pushout h^, which “knows” how to avoid name clashes between 
visible symbols defined in M and visible symbols that may accidentally occur 
in some of the actual parameters; 

4. Calculate ft<i>’s pushout {h<p)s, which solves further name conflicts with M’s 
private symbols; and 

5. Rename all sentences declared in M accordingly. 

Notice that all these steps are purely textual and can be efficiently implemented. 

Proposition 11. In the context of Definition 10, 

1. h^: M ^ M[hi, ..., ft„] is a module morphism, 

2. Uj=i ^ ■ All J- • • • J- M„ M[hi, ..., hn] is also a morphism, and 

3. M\h \, ..., fty,] = M 'k h(p J- Ml J- * * * “t“ Mji . 
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Proof: For 1., h^: M ^ M\hi, hn] is a morphism because: 



h^{Vth{M)) = h${Th^{A)) 






c 



((/l<g)i;(A)) 



(Lemma 1) 









= Vth{M[hi 



'{{h.p)s{A) U U”=i Aj) (Proposition 4) 
h„]) ■ 



2. is straightforward, J^ecause by Proposition 4, ^ 

j=i j=i 

3. follows from the equalities 



AI 'k All F ' * * F AIji 

= (^5 A) k h,p + (iFi, f?i, Ai) + • • • + {'An, fin, An) 

= {Ah, f^{h 4 ,), {h<p)s{A)) + {Ai, fii, Ai) + • • • + {An, fin, An) (Def. 7) 
= {Ah U U”=i A„E^h,) U U”=i (/i<z>)i:(^) U U”=i (Def. 6) 

= {Ah, U U”=i {h.,)s{A) U U”=i 

= , (Def. 10) 

using Proposition 4. 



□ 



This proposition suggests the following for the two semantics of instantiating 
a parameterized module: 

Definition 11 . Using the same context and notation as in Definition 10, let 
{M[hi,...,hn]l-^ = Vth{Ah,E^^h^)\j\J'.^-^f2j,{h.i.)s{A) \J[fj=iAj) and also let 
..., hn]l 2 ~ {f'“p{ Vth{AI)) U Uj=i Vth{Mj))* , where closure is over Ah- 

The following gives sufficient and necessary conditions under which the two 
semantics for the result module coincide, and shows that conservativity of the 
result module does not depend on conservativity of its original interface: 
Proposition 12 . In the context of Definition 10, if the given institution is dis- 
tributive and if 

1. AI, All, Mn are conservative, 

2. E(h^) n fij = Aj for j = 1, ..., n, and 

3. fii n fij = Air\ Aj for i,j = 1, ..., n, with Ali yf Alj, 
then 

1. \M\hi , ..., hn]\i = \M[hi , ..., hn]\2 , 

2. m\= AI[hi , ..., hn] ijf rn\h^ H ^ and |= Alj for any Ah-model m, 

3. AI[hi, ...,hn] is conservative. 

Proof: By Propositions 11 and 7, Vth{AI k h,p) = h,p{Vth{AI))* and AI k h^ 

is conservative, where the closure is over <?ft,-sentences. Since AI[hi, ...,hn] = 
M k h^, + All + • • • + Ain, iteratively applying Propositions 11 and 6 we get 
that Vth{A[[hi, ..., hn]) = {h,p{Vth{AI))* U Uj=i AI[hi, ..., hn] is 

conservative, where the closures are over <?^-sentences. □ 



The conservativity of AI, AIi , ..., M„ and the equalities fii n fij =Aif] Aj are 
needed because of 3. in Proposition 11 and because of their necessity in Proposi- 
tions 6 and 7. The condition E(^h^)Dfij = Aj may look restrictive, but in practice 
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it is not, since informally, it says that an implementation should either rename 
some private symbols in M in the instantiated module to avoid conflicts with 
private symbols in Mj , or else rename some symbols in Mj before the instantia- 
tion is done. This assumption is needed because Proposition 6 requires that the 
modules involved in a sum have pairwise disjoint private symbols; condition 2. 
concerns the pairs involving the module M while condition 3. concerns the 
remaining pairs. 

An important general property of parameterization is that the instantiated 
module is a colimit. This can be proved in a logic independent framework for 
modules which respect the above natural requirements: 

Theorem 2. In the context of Proposition 12, if Sij are {I'iOl'j) -modules^ such 
that Vth{Sij) C Vth{Mi) n Vth{Mj), then M[hi, ...,hn] is a colimit of 




where is the inclusion Hi n Hj ^ Hi, for i,j = 1, ...,n. 

Proof: Notice that : Sij Mi are module morphisms, and that giving a 

cocone of the diagram above is equivalent to giving a module C, a morphism 
/ : M ^ C, and morphisms Qj : Mj C such that 

1. hi] Qi = af, If, / for i = 1, ..., n, and 

2. i\j;gi = for i,j = l,...,n. 

The diagram below may help the reader follow the rest of this proof. 




® Think of Sij as the shared modules of Mi and Mj. 




Composing Hidden Information Modules over Inclusive Institutions 



119 



First we show that h,p: M ^ M[hi, hn] with Wi ^ <l>h' Mi ^ M[h\, /i„] 
for t = 1, n is a cocone: 

h,] (If, ^h) = (a*; K; ((iF, Uj=i (Uj=i '^3 ^ ^h)) 

= a.; ((a-i; hi )- ^ U”=i '^.)); (U;=i -- ^h) 

= ((<?* -- U”=1 <?.); ^); (U”=1 ^3 

= ^ u;=i (/^; (U ”=1 -- <^^)) 

= - U”=1 <?.); ((U”=1 <^3 -- 

= m -- U”=i <?.); (U”=i -- <^)); h., 

— ct^, Zj, hip . 

Also, it is straightforward that z-^; (iFi ^ = zA; (<Fj ^ because there is 

only one inclusion ']/i n <Fj ^ <Ph- 

Now let / : M ^ C and gi : Mi C for z = 1, ..., rz be another cocone, with 
C = (>F, 17, B). Then <F with the signature morphisms gi: <Fi ^ <F for z = 1, ..., rz 
form a cocone in Sign for the diagram given by the pairs of inclusions 

ipi ^ ^1'i n C ^ 

for i, j = 1, ..., rz, so by 2. of Proposition 1, there is a unique signature morphism, 
let us call it g : Uj=i ^3 such that {^i ^ Uj=i ^j)'i9 = 9i- Since 

U”=1 ((U”=1 ^3 <^); /) = m U”=1 (U”=i ^3 m f 

= 

(cz^ , Oz), Zz, f 
, (oz, Zz, /*) 

= cZj ; (/zzj gi) 

= (cZj ; ft-z); gi 

= {a-^-,h,)-,m^[jU'^3);9) 

= ((«-'; /z,);('F.-zU”=i>^,)); 5 

by 1. of Proposition 1, we get (Uj=i ^ ^); / = ff- But the rightmost square 
in the diagram at the beginning of this proof is a pushout, so there is a unique 
r: such that h,p-,r = f and (U”=i ^ ^h)', r = g. 

We claim that r is a module morphism, from M[hi, ..., hn] to C. Indeed, 



r{Vth{M[hi , ..., hn])) = r{{h^{Vth{M)) U Vth(Mj))*) 

C r{h^{Vth{M)) U U”=i Vth{Mj))* 

= {r{h^{Vth{M))) U U”=i r{Vth{Mj)))^ 

= {f{Vth{M)) U U”=i gj{Vth{M,)))' 

C Vth{C)* 

= Vth{C) . 

The first line above follows by 1. of Proposition 12, and the second by the Closure 
Lemma. The uniqueness of r: M[hi, h„] —>■ C follows from the uniqueness 
of r : ^ ^ as a signature morphism. Let r' : M[hi , ..., hn] C he another 
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morphism such that h^; r' = f and (S'i ^ ^/i); r' = §i for i = 1, n. Since the 
inclusions 'f'i ^ Uj=i epimorphic family and 

^ u;=i ((u;=i 'I'j ^ ^h); r') = m ^ u;=i ’I'j); (U”=1 ^ ^h)); r' 

= (If, ^h)-,r' 

= {k-^uu'^^y^9, 

by 1. of Proposition 1, (Uj=i '^j ^ ’^h)', r' = g. By the uniqueness of r : — > !f 

with h^] r = f and (Uj=i ^ ^h)', r = g, it follows that r' = r. □ 



Many practical modules have just one parameter, in which case sharing between 
actual parameters is not a problem, and a simpler result can be stated: 



Corollary 3. In the context of Proposition 12, if M[ai :: Pi] is a parameterized 
module and if hi: Pi ^ Mi is a module morphism, then the square 



ai ;2i 

Pi — -^M 



Ml 



■M 



hi] 



is a pushout in MSpec, where h = a ^;hi and i: !fi ^ <Ph- 



Proof: By Theorem 2 with S'!! = Mi. 



□ 



6 Conclusions and Future Research 

This paper studies the composition of modules that can hide information, over 
inclusive institutions, a class which appears to include all logical systems of 
practical interest. Two different semantics for composed modules were defined, 
and it was shown that they agree if all the modules involved are conservative. In 
addition, a number of basic “laws of software composition” were proved; these 
assert that two different module compositions have the same semantics, for all 
instances of their variables that range over modules. An important conclusion 
is that inclusive institutions can greatly simplify the kind of proofs done in 
this paper. This setting also allows algorithms for flattening compositions to 
be presented as mainly based on signatures pushouts, which is a purely textual 
operation for concrete institutions. In addition, we have given a brief institutional 
explanation for why our approach applies to programs as well as to specifications. 

In addition to the applications discussed in the introduction to powerful 
module systems for programming and specification languages, and its emerging 
applications to database and meta-data integration, the ideas of parameterized 
programming, as refined and extended in this paper, seem promising for many 
other areas involving knowledge representation, as was already suggested in the 
original paper on Clear [7]. Examples of such promising areas include the se- 
mantic web [16], ontologies for scientific research, cognitive linguistics [17], and 
business workflow models. 
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Some interesting directions for future theoretical research include the follow- 
ing: extend the results of this paper to a multi-institutional framework (e.g., see 
[13,41]) to accommodate multi-paradigm specification languages; prove further 
laws, such as distributivity (see [2,15]); and adapt the normalization theorem 
of [2] to our setting. It would also be interesting to develop an algorithm for 
pushouts of the usual signatures, that is closed under horizontal and/or vertical 
composition in the sense of Convention 1; an implementation (e.g., in Perl) of 
the composition operations using this algorithm could be useful for a wide range 
of applications. 
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Abstract. A verifying compiler is one that proves mechanically that a 
program is correct before allowing it to be run. Correctness of a pro- 
gram is defined by placing assertions at strategic points in the program 
text, particularly at the interfaces between its components. From re- 
cent enquiries among software developers at Microsoft, I have discovered 
that assertions are already used widely in program development prac- 
tice. Their main role is as test oracles, to detect programming errors as 
close as possible to their place of occurrence. Further progress in reliable 
software engineering is currently supported by programmer productiv- 
ity tools. I conjecture that these will be developed to exploit assertions 
of various kinds in various ways at all stages in program development. 
Eventually assertions will be used more widely for their original purpose 
of establishing important aspects of the correctness of large programs. 
However, the construction of a fully verifying compiler remains as a long- 
term challenge for twenty-first century Computing Science. 



1 Historical Introduction 

An assertion in its most familiar form is a Boolean expression that is written as 
an executable statement at any point in the program text. It can in principle 
or in practice be evaluated by the computer, whenever control reaches that 
point in the program. If an assertion ever evaluates to false, the program is by 
definition incorrect. But if all assertions always evaluate to true, then at least no 
program defect has ever been detected. But best of all, if it can be proved that 
the assertion will always evaluate to true on every possible execution, then the 
program is certainly correct, at least insofar as correctness has been captured by 
the assertions embedded in it. The construction and validation of such proofs 
are the goal of the verifying compiler. 

An understanding of the role of assertions in Checking a Large Routine [Tur- 
ing] goes back to Alan Turing in 1949. The idea of a verifying compiler, which 
uses automatic theorem proving to guarantee the correctness of the assertions, 
goes back to Bob Floyd [Floyd]. And the idea of writing the assertions even 
before writing the program was propounded in 1968 by Edsger Dijkstra in an 
article on a Constructive Approach to the Problem of Program Correctness [Di- 
jkstra]. Dijkstra’s insight has been the inspiration of much of the research in 
formal methods of software engineering conducted in University Computing De- 
partments over the last thirty years. 
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Ole- Johan Dahl has made many contributions to research on program correct- 
ness. He began by extending program correctness reasoning to semicoroutines 
[Dahll], a disciplined structure for quasi-parallel programming which had been 
introduced in Simula. In [Dahl2] he discussed a question that still deserves an 
answer today: can program proving be made practical? In [Dahl3] and [Dahl4] 
he began to extend specification and verification technology to object-oriented 
programming. In [Dahl, Owe] and [Dahl5] he applied formal analytic techniques 
based on assertions to the design of new programming language features, particu- 
larly those that are relevant for reliable exploitation of concurrency. Correctness 
of concurrent object-oriented programs is of increasing concern in the present 
day. Finally, a complete treatment of verifiable programming is the topic of his 
major textbook [Dahl6j. 

([Dahl5] reports a presentation that Ole- Johan gave at a symposium to mark 
my retirement from Oxford University in 1999. During his presentation, all 
the lights in the building went out. He was able to complete his presentation in 
darkness, maintaining the rapt attention of his audience. None of the subsequent 
speakers were prepared to match this achievement, so the symposium adjourned 
until the electricians could restore power.) 

Early attempts to implement a verifying compiler were frustrated by the 
inherent difficulties of mechanical theorem proving. These difficulties have in- 
spired productive research in a number of directions, and with the aid of massive 
increases in computer power and capacity considerable progress has been made. 
I suggest that an intensification of cooperative research efforts will result in the 
emergence of a workable verifying compiler some time in the current century. 

A second problem has been that meaningful assertions are notoriously dif- 
ficult to write. Computers are most widely applied in areas such as commerce 
and in social interactions, where there is no generally accepted framework of sci- 
entific concepts to help in the formulation of specifications and the elucidation 
of assumptions and preconditions for the successful use of a software service. 
Much of the code in use today contains very few assertions. Few of the inter- 
nal interfaces have any sort of formal specification. This means that there is 
no body of test material against which progress in program verification can be 
assessed. A third problem has been that the benefits of assertions have been 
insufficiently recognised to motivate their wider use by programmers. Many 
graduates of reputable Computing Science degrees never encounter assertions in 
their entire university education. Assertions are not adequately supported by 
current programming languages, and they are not widely exploited in current 
program development environments. But these negative factors are gradually 
being overcome. In sections 2 and 3, I will present evidence for the increasing 
role of assertions in todays programming practice. 

But by far the greatest problem for program verification has always been lack 
of market demand. For many years, my friends in the software industry have told 
me that in all surveys of customer requirements the top two priorities have always 
been firstly an increase in features, and secondly an increase in performance. 
Reliability takes only the third place. But now it seems that widely available 
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software already provides enough features to satisfy nearly all demands, and 
widely available hardware already satisfies most demands for performance and 
capacity. The main remaining obstacle to the full integration of computers into 
industry and commerce and into the life of society as a whole is a wide-spread 
and well-justified reluctance to trust the software. A recent email [Gates] by 
Bill Gates to Microsoft and all its subsidiaries has put trustworthy computing 
at the head of the policy agenda. This policy has already been put into force 
by devoting the efforts of the entire Microsoft Windows team during the whole 
month of February 2002 to a software security drive. Expensive it has been, but 
not as expensive as some recent viruses like Gode Red, which have led to world- 
wide losses estimated at over a billion dollars. In the long run, it is satisfaction of 
market demand for software reliability, and reduction in the high cost of program 
testing, that will motivate adoption of a verifying compiler in normal program 
development practice. 



2 Assertions in Program Testing 

In my thirty years as an academic scientist, I pursued the traditional academic 
ideals of rigour and precision in scientific research. I sought to enlarge our un- 
derstanding of the theory of programming to show that large-scale programs can 
be fully specified and proved to be correct with absolute mathematical certainty. 
I hoped that increased rigour in top-down program development would signifi- 
cantly reduce if not eliminate the burden of program testing and debugging. I 
would quote with approval the famous dictum of Dijkstra, that program testing 
can prove the existence of program bugs, but never their absence. 

A very similar remark was made by the famous philosopher Karl Popper. 
His Philosophy of Science is based on the principle of falsification, namely that 
a scientific theory can never be verified by scientific experiment; it can only be 
falsified. I accept his view that a scientific advance starts with a theory that 
has some a priori grounds for credibility, for example, by deduction from the 
principle that a force has an effect that is inversely proportional to the square 
of the distance at which it acts. A new theory that applies such a principle to 
a new phenomenon is subjected to a battery of tests that have been specifically 
designed, not to support the theory, but rather to refute it. If the theory passes 
all the tests, it will be used with confidence to help in the formulation and test of 
further and more advanced theories, and in the design of experiments to refute 
them. 

Extending this analogy to computer software, we can see clearly why pro- 
gram testing is in practice such a good assurance of the reliability of software. 
A competent programmer always has a prior understanding, perhaps quite in- 
tuitive, of the reasons why the program is going to work. If this hypothesis 
survives a rigorous testing regime, the software has proved itself worthy of deliv- 
ery to a customer. If a few small changes are needed to correct minor anomalies 
in the program, they are quickly made — unfortunate perhaps, but that hap- 
pens to scientific theories too. In Microsoft, every project has assigned to it a 
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team of testers, recruited specially for their skill as experimental scientists; they 
constitute about a half of the entire program development staff on each project. 

This account of the vital role of testing in the progress of science is rein- 
forced by consideration of the role of test in engineering. In all its branches, 
rigorous product test is an essential prerequisite before shipping a new or im- 
proved product to the customer. For example, in the development of a new aero 
jet engine, an early working model is installed on an engineering test bench for 
exhaustive trials. This model engine will first be thoroughly instrumented by 
insertion of test probes at every accessible internal and external interface. An 
exhaustive test schedule is designed to exercise the engine at all the extremes 
of its intended operating range. By continuously checking tolerances at all the 
crucial internal interfaces, the engineer detects incipient errors immediately, and 
never needs to test the assembly as a whole to destruction. By continuously 
striving to improve the set points and tighten the tolerances at each interface, 
the quality of the whole product can be gradually raised. That is the essence 
of the six sigma quality improvement philosophy, which has been widely ap- 
plied in manufacturing industry to increase profits at the same time as customer 
satisfaction. 

In the engineering of software, assertions at the interfaces between modules 
of the program play the same role as test probes in engine design. This ana- 
logy with engineering instrumentation suggests that programmers should devote 
effort to increase in the number and strength of assertions in their code. This 
will make their system more likely to fail under test; but the reward is that it is 
subsequently much less likely to fail in the field. 

In the three years since I retired from academic life, I have been working in 
the software industry. This has enabled me to balance the idealism that inspires 
academic research with the practical compromises that are essential to industrial 
engineering. In particular, I have radically changed my attitude towards program 
testing, which I now understand to be entirely complementary to scientific design 
and verification methods; testing makes an equally essential contribution to the 
development of reliable software on an industrial scale. It is no accident that 
program testing exploits the same kind of specifications by assertions that form 
the basis of program verification. 



3 Assertions in Current Microsoft Development Practice 

In this section I will describe some of the ways in which I have found that asser- 
tions are already exploited by program developers in Microsoft Corporation. I 
have grounds for believing that many other Companies find them just as useful. 
Their main use is not for program verification but as a test oracle during the de- 
bugging phase of development. The fact that they are useful for many purposes 
besides verification is encouraging, because it shows that programmers can al- 
ready be persuaded to annotate their programs with reliable assertions. Indeed, 
because they are so thoroughly tested every time the program is changed, they 
are widely regarded as the only reliable form of program documentation. 
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The defining characteristic of an engineering test probe is that it is removed 
from the engine before manufacture and delivery to the customer. In computer 
programs, this effect is achieved by means of a conditionally defined macro. The 
macro is resolved at compile time in one of two ways, depending on a compile- 
time switch called DEBUG, set for a debugging run, and unset when compiling 
code that will be shipped to the retail customer. An assertion may be placed 
anywhere in the middle of executable code by means of this ASSERT macro, which 
is typically declared 

#ifdef DEBUG 
#define ASSERT (b,str) 

if (b) 

else report (str) ; assert (false) 

#else #define ASSERT (b, str) 

#endif 

In addition to their role in product test, assertions are widely recommended 
as a form of program documentation. This is of vital concern to major soft- 
ware suppliers today, because their main development activity is the continuous 
evolution and improvement of old code to meet new market needs. Even quite 
trivial assertions, like the following, give added value when the code is modified 
for a subsequent release of the product. 

if (a >= b) ... a++ ; ... ; 

ASSERT(a != b, ?a has just been incremented to avoid equality’) ; 

X = c/(a - b) 

One development manager in Microsoft recommends that for every bug cor- 
rected in test, an assertion should be added to the code which will fire if that 
bug ever occurs again. Ideally, there should be enough assertions in a program 
that nearly all bugs are caught by assertion failure, because that is much easier 
to diagnose than other forms of failure, for example, a crash. Some developers 
are willing to spend a whole day to design precautions that will avoid a week’s 
work tracing an error that may be introduced later, when the code is modified 
by a less experienced programmer. Success in such documentation by assertions 
depends on long experience and careful judgment in predicting the most likely 
errors a year or more from now. Not everyone can spare the time to do this un- 
der pressure of tight delivery schedules. But it is likely that a liberal sprinkling 
of assertions in the code would increase the accumulated value of legacy, when 
the time comes to develop a new release of the software. 

In the early testing of a prototype program, the developer wants to check 
out the main paths in the code before dealing with all the exceptional conditions 
that may occur in practice. In order to document such a development plan, some 
developers have introduced a variety of assertion which is called a simplifying 
assumption. 
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SIMPLIFYING_ASSUMPTION 

(strlen(input) < MAX_PATH, ’not yet checking for overflow’) 

The assumption documents exactly the cases which the developer is not yet 
ready to treat, and it also serves as a reminder of what remains to do later. 
Violation of such assumptions in test will simply cause a test case to be ignored, 
and should not be treated as an error. Of course, in compiling retail code for 
delivery to the customer, the debug flag is not set; and then the macro will give 
rise to a compile-time error; it will not just be ignored like an ordinary assertion. 
This gives a guarantee against the risk incurred by more informal comments and 
messages about known bugs and work that is still TO DO; such comments have 
occasionally and embarrassingly found their way into code shipped by Microsoft. 

All the best fault diagnoses are those given at compile time, since that is 
much cheaper than diagnosis of errors by test. In one product team in Microsoft, 
a special class of assertion has been implemented called a compile-time check, 
because its value, true or false, can be computed at compile time. 

COMPILE_TIME_CHECK (sizeof (x) ==sizeof (y) , 

’addition is undefined for arrays of different sizes’) 

The compile time error message is generated by a macro that expands to an 
invalid declaration (negative array bound) in C when the condition evaluates 
to false; of course, each use of the compile time assertion must be restricted to 
use only values and functions computable by the compiler. (The compiler will 
complain if not.) The example above shows a test of conformity of the size of 
two array parameters for a method. Of course, as we make progress towards a 
verifying compiler, the aim will be to increase the proportion of assertions whose 
potential violation will be detected at compile time. 

Assertions can help a compiler produce better code. For example, in a C- 
style case statement, a default clause that cannot be reached can be marked 
with an UNREACHABLE assertion, and a compiler (for example Visual C) avoids 
emission of unnecessary code for this case. 

switch (condition) 
case 0 : ... ; break; 

case 1 : ... ; break; 

default: UNREACHABLE( ’ condition is really a boolean’); 

In future, perhaps assertions will give further help in optimisation, for exam- 
ple by asserting that pointers or references do not point to the same location. 
Of course, if such an assertion were false, the effect of the optimisation could 
be awful. But fortunately assertions which have been frequently tested are re- 
markably reliable; indeed, they are widely believed to be the only believable 
form of program documentation. When assertions are automatically proved by 
a verifying compiler, they will be even more believable. 

A global program analysis tool called PREflx [Bush] is now widely used by 
Microsoft development teams. Like Lint [Johnson], its role is to detect pro- 
gram defects at the earliest possible stage, even before the program is compiled. 
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Typical defects are a NULL pointer reference, an array subscript out of bound, 
a variable not initialised. PREfix works by analysing all paths through each 
method body, and it gives a report for each path on which there may be a de- 
fect. The trouble is that most of the paths can never in fact be activated. The 
resulting false positive messages are called noise, and they still require consider- 
able human effort to analyse and reject; and the rejection of noise is itself highly 
prone to error. It is rumoured that the recent Code Red virus gained access 
through a loophole that had been detected by PREfix and deliberately ignored. 

Assertions can help the PREfix anomaly checker to avoid unnecessary noise. 
If something has only just three lines ago been inserted in a table, it is annoying 
to be told that it might not be there. A special ASSUME macro allows the pro- 
grammer to tell PREfix relevant information about the program that cannot at 
present be automatically deduced. 

pointer = find (something); 

PREFIX_ASSUME ( pointer != NULL, 

’see the insertion three lines back’); 
pointer ->mumble = blat ; 

Assertions feature strongly in the code for Microsoft Office — around a quar- 
ter of a million of them. They are automatically given unique tags, so that 
they can be tracked in successive tests, builds and releases of the product, even 
though their line-number changes with the program code. Assertion violations 
are recorded in RAID, the standard data base of unresolved issues. When the 
same fault is detected by two different test cases, it is twice as easy to diag- 
nose, and twice as valuable to correct. This kind of fault classification defines 
an important part of the team’s programming process. 

In Microsoft, over half the effort devoted to program development is at- 
tributed to test. For legacy code, there is an accumulation of regression tests 
that are run for many weeks before each new release. It is therefore very impor- 
tant to select tests that are exceptionally rigorous, so as to increase the chance 
of catching bugs before delivery. Obviously, tests that have in the past violated 
assertions are the most important to run again. Violation of a simplifying as- 
sumption is a particular reason for increasing the priority of a test , because it is 
likely to exercise a rare and difficult case. 

The original purpose of assertions was to ensure that program defects are 
detected as early as possible in test, rather than after delivery. But the power of 
the customer’s processor is constantly increasing, and the frequency of delivery 
of software upgrades is also increasing. It is therefore more and more cost- 
effective to leave a moderate proportion of the assertions in shipped code; when 
they fire they generate an exception, and the choice is offered to the customer of 
sending a bug report to Microsoft. The report includes a dump of the stack of 
the running program. About a million such reports arrive in Redmond every day 
for statistical assessment, and the more frequent ones are corrected in service 
packs. A controlled restart resulting from assertion failure is much better than 
a crash, which is otherwise a likely result of entry into a region of code that has 
never been encountered in test. 
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4 Assertions in Programming Languages 

The examples of the previous section have all been implemented as macro def- 
initions by various teams in Microsoft, and each of them is used only by the 
team which implemented them. In the code for Microsoft Windows, we have 
found over a thousand different assertion macro declarations. This constitutes a 
serious impediment to the deployment of a standard programming analysis tool 
to exploit assertions. The best way of solving this problem in the long term is 
to include an adequate range of assertions into the basic programming language. 
A standard notation is likely to be more widely accepted, more widely taught, 
and more widely used than a macro devised by an individual programmer or 
programming team. Furthermore, inclusion of assertions in the language would 
remind the language designer of the desirability of helping programmers in their 
most difficult task, namely that of establishing confidence in the correctness 
of their programs. As I suggested when I first started research on assertions 
[Hoarel], provision of support for sound reasoning about program correctness is 
a suitably objective and scientific criterion for judging the quality of a program- 
ming language design. 

Significant progress towards this goal has been made by Bertrand Meyer in 
his design of the Eiffel programming language [Meyer]. Assertions are recom- 
mended as a sort of contract between the implementers and the users of a library 
of classes; each side undertakes certain obligations in return for corresponding 
guarantees from the other. The same ideas are incorporated in draft proposals 
for assertion conventions adapted for specifying Java programs. Two examples 
are the Java modelling language JML [Leavens et ah] and the Extended Static 
Checker ESC for Modula 3 and Java [Leino et al.j. ESC is already an educational 
prototype of a verifying compiler. 

Assertions at interfaces presented by a library give exceptionally good value. 
Firstly, they are exploited at least twice, once by the implementer of the interface 
and possibly many times by all its users. Secondly, interfaces are usually more 
stable than code, so the assertions that define an interface are used repeatedly 
whenever library code or user code is enhanced for a later release. Interface 
assertions permit unit testing of each module separately from the programs that 
use it; and they give guidance in the design of rigorous test cases. Finally, they 
enable the analysis and proof of a large system to be split into smaller parts, 
designed and checked separately for each module. This is absolutely critical. 
Even with fully modular checking, the first application of PREfix to a twenty 
million line product took three weeks of machine time to complete the analysis; 
and even after a series of optimisations and compromises, it still takes three 
days. A faster analysis tool is now available for more frequent modular use. 

Three useful kinds of assertions at interfaces are preconditions, postcondi- 
tions and invariants. A precondition is defined as an assertion made at the 
beginning of a method body. It is the caller of the method rather than the 
implementer who is responsible for the validity of the precondition on entry; 
the implementer of the body of the method can just take it as an assumption. 
Recognition of this division of responsibility protects the virtuous writer of a 
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precondition from having to inspect faults which have been caused by a careless 
caller of the method. In the design of test cases for unit test, each case must be 
generated or designed to satisfy the precondition, preferably at the edges of its 
range of validity. 

A post- condition is an assertion which describes (at least partially) the pur- 
pose of a method call. The caller of a method is allowed to assume its validity. 
The obligation is on the writer of the method to ensure that the post-condition is 
always satisfied. Test cases for unit test must be generated or designed with the 
best possible chance of falsifying the postcondition. In fact, postconditions and 
other assertions should be so strong that they are almost certain to find any de- 
fect in the program. As with a scientific theory, it should be almost inconceivable 
that an incorrect program will escape detection by one of the tests. 

In object oriented programs, preconditions and post-conditions document the 
contract between the implementer and the user of the methods of a class. The 
interface between successive calls of different methods of an object of the class is 
specified by means of an invariant. An invariant is defined as an assertion that 
is intended to be true of every object of a class at all times except while the code 
of the class is executing. It can be specified as a suitably named boolean method 
of the same class. An invariant does not usually feature as part of the external 
specification of a class; but rather describes the strategy of the implementation 
of the individual methods. For example, in a class that maintains a private list 
of objects, the invariant could state the implementer’s intention that the list 
should always be circular. While the program is under test, the invariant can 
be retested after each method call, or even before as well. 

Invariants are widely used today in software engineering practice, though 
not under the same name. For example, every time a PC is switched on, or 
a new application is launched, invariants are used to check the integrity of the 
current environment and of the stored data base. In the Microsoft Office project, 
invariants on the structure of the heap are used to help diagnose storage leaks. 
In the telephone industry, they have been used by a software auditing process, 
which runs concurrently with the switching software in an electronic exchange. 
Any call records that are found to violate the invariant are just re-initialised or 
deleted. It is rumoured that this technique once raised the reliability of a newly 
developed telephone switching system from undeliverable to irreproachable. 

In Microsoft, I see a future role for invariants in post-mortem dump-cracking, 
to check whether a failure was caused perhaps by some incident long ago that 
corrupted data on the heap. This test has to be made on the customer machine, 
because the heap is too voluminous to communicate in totality to a central 
server. There is a prospect that the code to conduct the tests will be injected 
into the customer’s software as the occasion demands. 

In summary, the primary use of assertions today is for program instrumen- 
tation; they are inserted as probes in program testing, and they serve as a test 
oracle to give early warning of program defects, close to the place that they 
occur. They are also used for program documentation, to assist later developers 
to evolve the product to meet new market needs. In particular, they specify 
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interfaces between major software components, such as libraries and applica- 
tion programs. Assertions are just beginning to be used by the C compiler in 
code optimisation. They are used to classify and track defects between customer 
sites, between test cases, and between code changes. Assertions are being intro- 
duced into program analysis tools like PREfix, to raise the precision of analysis 
and reduce the noise of false positives. Increasingly, assertions are shipped to 
the customer to make a program more rugged, by forestalling errors that might 
otherwise lead to a crash. 

At present, Microsoft programmers find it profitable to formulate assertions 
that achieve each of these benefits separately. Even more profitable would be to 
obtain all these benefits together, by reusing the same assertion again and again 
for different purposes at different stages in the progress of a project. In this way, 
programmers will be encouraged to introduce assertions as early as possible 
into the development process. They can then play a guiding role in a top- 
down process of program design, as suggested in Dijkstra’s original constructive 
approach to correctness. 

5 The Future 

I expect that assertions will bring even greater benefits in the future, when they 
are fully supported by a range of programmer productivity tools. They will help 
in deep diagnosis of post-mortem dumps. They will serve as a guide in test case 
generation and prioritisation. They will help to make code concurrency-safe, and 
to reduce security loop-holes. In dealing with concurrency and security, there is 
still plenty of scope for fundamental research in the theory of programming. 

In conclusion, I would like to re-iterate the research goal which I put forward 
[Hoard] when I first embarked on research into program correctness based on 
assertions. It was to enable future programming languages and features to be 
designed from the beginning to support reasoning about the correctness of pro- 
grams. In this way, I hoped to establish an objective criterion for evaluating the 
quality of the language design. I believe that modern language designers, includ- 
ing the designers of Java and C#, are beginning to recognise this as a valuable 
goal, though they have not yet had the idea of using assertions to help them 
achieve it. As a result, these languages still include a number of fashionable 
features, and low-level constructions which are often motivated by the desire to 
contribute to efficiency. Unfortunately, these features can make it difficult or 
impossible to use local reasoning about the correctness of a component, in the 
assurance that correctness will be preserved when the components are assembled 
into a large system. 

Fortunately, these problems are soluble even without a switch to a more 
disciplined programming language. Program analysis tools like PREfix show 
the way [Bush, Evans]. By conducting an analysis of the source code for the 
entire system, it is possible to identify the use of the more dangerous features of a 
programming language, which can be objectively identified as those which violate 
modularity and invalidate normal correctness reasoning. A notorious example is 
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the introduction of aliasing by passing the same (or overlapping) parameter more 
than once by reference to the same procedure call. Such violations are flagged by 
a warning message. Of course, the warnings can be ignored. But in Microsoft, 
at least, there is a growing reluctance to ignore warning messages. It is a brave 
programmer who has the confidence to guarantee program correctness in the 
face of such a warning, when the penalty for incorrectness is the introduction 
of a virus that causes a billion dollars of damage. And when all programmers 
rewrite their code to eliminate all such warnings, they are effectively already 
using a much improved programming language, essentially a safe subset of the 
original legacy language. 

A second promising development for users of legacy languages is the design 
pattern [Gamma et al.]. A design pattern is based on some coherent program 
structuring concept, whose purpose is carefully explained. It consists of a collec- 
tion of code fragments that can be inserted into the users own program, together 
with a set of protocols and design disciplines to be observed in the rest of the 
program, to ensure the integrity of the program structure. It is likely that pro- 
gram analysis tools will evolve to police the observance of such disciplines. In 
effect, an advanced program analyser will come to resemble a compiler for an im- 
proved language, with new and potentially verifiable features included as design 
patterns, and known defects of existing languages removed. And these benefits 
are obtained effectively without any abrupt change of notation for writing the 
code. 

These are the reasons for optimism that professional programmers in the 
software industry will be ready to accept and use a verifying compiler, when 
it becomes available. In industry, work towards the evolution of a verifying 
compiler will progress gradually by increasing the sophistication of program 
analysis tools. But there is a splendid opportunity for academic research to lead 
the way towards the longer term future. I have already mentioned the verifying 
compiler as one of the major challenges of Computing Science in the twenty first 
century. To meet the challenge we will need to draw on contributions from all the 
different technologies relevant to mechanised proof. Like the Human Genome 
project, or the launch of a new scientific satellite, or the design of a sub-atomic 
particle accelerator, progress on such a vast project will depend on a degree of 
collaboration among scientists that is so far unprecedented in Computer Science. 

There is now a great mass of legacy software available as test material for 
evaluating progress towards software verification. Work can start by annotating 
and improving the quality of the interfaces to the base class libraries, which 
come with the major object oriented languages. The work will be meticulous, 
exhausting and like most of scientific research, it will include a large element of 
routine. It will require deep commitment, and wide collaboration, and certainly 
the occasional breakthrough. Fortunately, the goal of the project is closely 
aligned with the ideals of the open source movement, which seeks to improve 
quality by contributions from many workers in the field. 

We will also need to recognise the complementary role of rigorous program 
testing; we must integrate verification with all the other productivity tools that 
are aimed at facilitating the program development process, including the main- 
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tenance and enhancement of legacy code. I expect that the use of full program 
verification will always be expensive; and the experienced software engineer will 
always have to use good engineering judgement in selecting a combination of 
verification and validation techniques to achieve confidence in correctness, relia- 
bility and serviceability of software. For safety critical software, the case for full 
verification is strongest. For operating system kernels and security protocols, 
it is already known that there is no viable alternative. For assurance of the 
structural integrity of a large software system, proof of avoidance of overflows 
and interference is extremely valuable. There will also be many cases where 
even a partial verification will permit a significant reduction in the volume and 
the cost of testing, which at present accounts for more than half the total cost 
of software development. Reduction in the high cost of testing and reduction 
in the interval to delivery of new releases will be major commercial incentives 
for the expansion of the role of verification; they will be just as persuasive as 
the pursuit of an ideal of absolute correctness, which has been the inspiration of 
scientific research in the area. In this respect, software engineering is no different 
from other branches of engineering, where well-judged compromises in the light 
of costs and timescales are just as important as an understanding of the relevant 
scientific principles, and skill in the application of the various tools. For further 
details about prospects for fulfilling the challenge of a Verifying Compiler, see 
[Hoare2] . 

The fact that formal software verification will not by itself solve all the prob- 
lems of software reliability should not discourage the scientific community from 
taking up the challenge. Like other major scientific challenges, the appeal of 
the project must be actually increased by its inherent difficulty. But the pri- 
mary motivation must be scientific: the pursuit of the old academic ideals of 
purity and integrity, and the enlargement of understanding by the discovery and 
exploitation of scientific truth. 
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Abstract. An object-oriented approach to program specification and 
verification was developed by Ole-Johan Dahl with the long-term Abel 
project. Essential here was the idea of reasoning about an object in terms 
of its observable behavior, where the specification of an object’s present 
behavior is given by means of its past interactions with the environment. 
In this paper, we review some of the ideas behind this approach and 
show how they can be fruitfully extended for reasoning about black-box 
components in open object-oriented distributed systems. 



1 Introduction 

Object-orientation was introduced by Ole-Johan Dahl and Kristen Nygaard with 
the programming language Simula [14, 15, 41, 13] in 1966. Since then, object- 
oriented programming (OOP) has become an increasingly widespread and popu- 
lar programming paradigm, lately with Java. Also for system specification, many 
formalisms have adapted ideas from OOP to better organize specifications; for 
example. Actors [2], Maude [9], Object-Z [46], UML [7], and the 7r-calculus [38] 
all support some object-oriented concepts. The term object-based has emerged to 
describe formalisms that support objects, i.e., that incorporate notions of object 
identity and encapsulation in the language [40]. To be fully object-oriented, a 
formalism should also have an inheritance mechanism reminiscent of OOP. We 
will now explain what we mean by the central object-oriented concepts of object 
identity, encapsulation, and inheritance in the context of specification notations: 

Identity. Objects have explicit identifiers. When communication occurs between 
named objects, an object knows which objects it addresses with a given 
communication. Object identifiers can be transmitted from one object to 
another during such communication. An object’s awareness of other objects 
in its environment can thus increase over time. 

Encapsulation and information hiding. An object encapsulates its internal vari- 
ables (attributes), so these are not directly perceived from outside the object. 
This has some noteworthy consequences. Internally, we gain control of how 
the object’s variables are manipulated. Variables can only be manipulated by 
operations (methods) that the object offers to its environment, so the state 
space of an object resembles an abstract data type. Externally, an object 
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appears as a black box that reacts in a (more or less) predictable manner 
to impulses from its environment. To use an object, knowledge of its im- 
plementation is not needed, only of the available methods. (Explicit hiding 
mechanisms were not present in the first version of Simula.) 

Inheritance. A subclass inherits a superclass by adding attributes and modify- 
ing or extending its methods. Class inheritance, introduced in Simula, is a 
powerful structuring mechanism for developing large systems. However, to 
really be of value, inheritance should not only allow reuse of code, but also 
of the reasoning done for the superclass [48] . A similar notion of inheritance 
or reuse at the level of reasoning can be found in behavioral (or predicate) 
subtyping [35]. In principle, these two notions of inheritance are not directly 
related, but when class inheritance is restricted to behavioral subtyping, we 
get substitutability, by which we mean that an object of a class C can be 
replaced by an object of a subclass of C at the level of reasoning.^ 

Restricting class inheritance to ensure behavioral subtyping comes at the 
expense of free code reuse and may seem too limiting in the eyes of many 
programmers. Also, combining these notions lead to the so-called inheritance 
anomalies [37]. In contrast, in the Abel project [10,11,16,12], Dahl takes the 
approach that reasoning is done at the specification level, and code is shown to 
implement specifications, for instance by means of type simulation. Hence, in 
Abel, a class can simulate a type. Requirement specification of a concurrent 
object is in terms of its observable behavior and may be implemented using (in- 
ternal) state transitions. The observable behavior of an object up to some point 
in time is recorded in its communication history (or finite trace), which gives us 
an abstract view of the object’s state, and present behavior can be specified as a 
function on the history. Traces are well-known from process algebra, for example 
CSP [25]. However, generator inductive specifications of the permissible traces 
as suggested by Dahl [10], where fix-points are not needed in the underlying 
semantics, are different from the process algebraic approach (as explained in 
Section 2.2). In contrast to approaches based on streams [33,8], specifications 
can be expressed by finite traces since the history at any given time is finite. 

In this paper, our focus is on formal reasoning and specification of open dis- 
tributed systems (ODS). These systems are subject to change at runtime, so we 
consider concurrent objects, and more generally components, that exist in an 
evolving environment. For instance, new objects can be introduced into the sys- 
tem and old objects can be upgraded or replaced. Objects will often be supplied 
by third party manufacturers and we cannot generally expect to have knowledge 
of implementation details concerning objects in the environment. Instead, the 
behavior of an object can be locally determined by its interaction with other 
objects in the environment [2], i.e. by its observable behavior. Due to the com- 
plexity of ODS, it is often advocated that system descriptions be aspectwise, in 
so-called viewpoints [26]. In this paper, we address the issue of specifying ODS 

® An early work on substitutability in the setting of class invariants, pre- and postcon- 
ditions on methods, and related requirements on method redefinition and external 
attribute access, is the thesis of Wang [50], snpervised by Dahl. 
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by viewpoints of observable object behavior, based on the tradition in object- 
oriented specification from Abel. 

The paper is structured as follows. In the next section, we give a brief 
overview of some important principles of object-oriented specification in Abel 
and suggest extensions towards ODS. Section 3 considers openness within the 
object-oriented framework. Section 4 introduces object viewpoints and behav- 
ioral interfaces in an assumption guarantee specification style [32], inspired by 
these principles. Section 5 illustrates the use of this formalism by a specification 
of a software bus, i.e. an open communication infrastructure. Section 6 discusses 
composition of assumption guarantee specifications in this setting and Section 7 
relates this work to other formalisms for specifying ODS and outlines future 
research issues before we conclude in Section 8. 

2 Object-Oriented Specification 

The Abstraction Building, Experimental Language (Abel) is a long-term re- 
search project at the University of Oslo, centered around a student course in 
formal methods and the development of a theorem prover. Abel is a wide spec- 
trum language, expressing requirement specifications, constructive specifications 
(models), and classes. The most important sources of ideas for Abel are object- 
orientation, especially the notions of class and subclass, which originated from 
the work on Simula; generator induction, from the work on Larch [23]; and 
order-sorted algebras, from the work on OBJ [22]. Program development in Abel 
consists of three steps: 

Applicative level. Specification in terms of observable behavior uses abstract 
data types, generator induction, and the local communication history. Sub- 
types are either syntactical (cf. examples) or predicative. Abel supports 
partial functions with partial logic [42]. 

Imperative level. Class implementation is state-based, establishing invariants 
by means of Hoare logic [24, 12], with the history as a mythical variable. 

Integration. The two levels are integrated by means of weak or strong simula- 
tion. A type can be simulated by a class. 

We will now consider each of the three steps and develop a brief example. 



2.1 The Applicative Level of Abel 

At an applicative level, specifications of concurrent objects are expressed by 
permissible observable behavior, i.e. by the time sequence of input and output to 
the program. This fits well with the object-oriented notion of encapsulation; only 
visible operations are considered at the applicative level and the realization of the 
object by means of internal data structures and implementation of operations 
is postponed to the imperative level. An execution can be represented by a 
sequence of communication events. In the case of non-terminating executions, 
the sequences are infinite. However, infinite sequences are not easy to reason 
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about. In order to avoid infinite sequences, specifications are expressed in terms 
of the finite initial segments of the executions, which express the abstract states 
of the object. These sequences are commonly referred to as histories [10] or 
traces [25]. An invariant on the history defines a set of traces by the prefix- 
closure of the set of executions, so history invariants express safety properties in 
the sense of Alpern and Schneider [3] . 

Dahl remarks that specifications in a generator inductive style closely resem- 
ble programs in an applicative programming language [12]. The values of an ab- 
stract data type are completely defined by its set of generator functions (or con- 
structors) in the sense that all inhabitants of the type can be generated by suc- 
cessive applications of the constructors. The definition f{xi, . . . ,x„) == RHS 
is terminating and generator inductive (TGI) if the right hand side RHS of the 
equation uses the variables xi, . . . , x„, the constructors, case constructs, / itself, 
and other TGI defined function symbols. In case of direct or indirect recursion, 
syntactic requirements guarantee termination. Specifications where all expres- 
sions are well-defined and only use TGI defined functions, can be evaluated in 
a convergent term rewrite system. Furthermore, for TGI defined functions, in- 
ductive arguments can be used in proofs; to each constructor corresponds one 
hypothesis in the proof rule. Such proofs can also to a large extent be mechanized 
by term rewrite systems. 

Finite sequences. We present an abstract data type specification in the Abel 
style for finite sequences parameterized over some type T. The type (schema) 
Seq[T] is defined as the union of two subtypes, Eseq, which is the type of the 
empty sequence over type T, and Seql[T], which is the type of non-empty se- 
quences over type T. 

typeSeq[T] by Eseq, Seql[T] == 

module 

func £ : ^ Eseq 

func ' h ' : Seq[T] x T ^ Seql[T] 
genbas £, ' h ' 

endmodule 

where " denotes argument positions of functions with mixfix notation. Here, the 
keyword genbas is used to indicate the functions used as a generator basis for 
the type, so the finite sequences are constructed from two generator functions; 
£ generates an empty sequence and s h x generates a non-empty sequence from 
a sequence s and en element x of type T. In Abel, finite sequences are defined 
by means of right append (suffix) rather than left append (prefix). 

Using TGI definitions, several functions can be constructively defined on 
the type of finite sequences Seq[T]. For instance, we can define left append 
" H ' : T X Seq[T] ^ Seql[T], concatenation " H ' : Seq[T] x Seq[T] ^ Seq[T], 
and length j) ' : Seq[T] ^ Nat by (case-free) equations: 



sH£=S tt£=0 

s H (t h x) = (s H t) h X j)(s F x) = t|s -I- 1 



X H £ = £ F X 

X H (s F j/) = (x H s) F y 
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In these function definitions, the free variables in each equation have an implicit 
universal quantifier, reminiscent of for instance ML, and each line corresponds 
to a possible generator case. 

Many useful functions are only partially defined on Seq[T], but TGI defined 
and total on the subtype Seql[T], which has only one generator (h). For instance, 
we can define selector functions: right rest rr(") : Seql[T] ^ Seq[T] and left term 
/t(") : Seql[T] ^ T by 

rr{e \~ x) = e lt{e \~ x) = x 

rr{{s \- y) \- X = rr{s \~ y)\- x lt{{s h j/) h x) = lt{s h y) 

The type of finite sequences and the functions we have defined above will now 
be used in an example specification. 

Example 1: We illustrate the applicative level of the Abel language by the 
specification of an unbounded buffer object. The buffer receives input by means 
of a get operation and transmits output by a put operation. The history of 
the buffer is a sequence of operation calls, conventionally denoted H, and new 
method invocations are recorded in the history by suffixing. Hence, the history 
until present time is always available for reasoning, and present behavior of 
the buffer is specified in terms of preceding activity. If we represent by a type 
Calls the put and get operations ranging over the values of a given type T, 
then H : Seq[Ca/Zs]. Given a history sequence, we define a function cut that 
computes the implicit content of the buffer, cnt : Seq [Ga/ls] ^ Seq[T]. Thus, the 
history gives us an abstract view of the state. The invariant of the specification 
is defined as a predicate on the history, which is updated after every method call. 
It follows that the history invariant is implicitly both pre- and postcondition of 
every operation in the interface. 

interface BufferSpec [T : Type] 

begin 

opr put{\n X : T) 
opr get{ovLt x : T) 
inv I{n) 
where 

I{e) = e 

I{Ti, h put{x)) = I{'H) 

I{H h get{x)) = I{H) A if cnt{H) yf £ then x = lt{cnt{H)) else false fi 
cnt{e) = e 

cnt{T-L h put{x)) = cnt{'H) F x 
cnt{T-L h get{x)) = rr{cnt{T-L)) 

end 

Both the invariant and the auxiliary function cnt are defined by terminat- 
ing generator induction. An invocation get{x) updates the mythical variable: 
:= h get{x). As new values are added to the right of the content sequence 
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(calculated by cnt{H)), the first value is retrieved by the left term function 
lt{cnt{H)) and the remaining content by the right rest function rr{cnt{'H)). □ 

2.2 The Imperative Level of Abel 

For the implementation of specifications in program code, a state-based guarded 
command language is suggested. The invocation of an operation implemented 
by G — > S, where G is a guard and S' is a program statement, must wait 
until G holds and results in the execution of S. The communication history 
is available at the implementation level as a “mythical” variable [12], which is 
implicitly updated with a new event representing the invocation of an operation 
after evaluation of the operation body. For verifying operations, Abel relies on 
Hoare-logic. Given a history invariant, verifying an operation call op{x) consists 
of establishing the validity of the formula {G A /(H)} S {/(H F op{x))}. 

Example 2: In this example, we propose a program code for the unbounded buffer 
specified in Example 2.1. The content of the buffer is stored in an internal variable 
cord : Seq[Tj. The program invariant is given by the relationship between the 
implicit content of the buffer, as extracted from the history, and the actual 
content which is stored in cord. 

class BufferClass [T : Type\ 
implements BufferSpec [T] 

begin 

var cord : Seq[T] 

opr put{\n X : T) == cont := cont h x 

opr ^et(out x : T) == cont yf e — > [x := lt{cont); cont := rr(cont)] 
inv cont = cnt{H) 

end 

The constructive nature of this form of applicative specifications is close 
to implementation, as illustrated by this program code for the specification of 
Example 2.1. In fact, this class implementation can be derived directly from 
the specification and the class invariant. (To obtain single transition systems, 
program statements can be restricted to multiple assignment operations although 
this is not done here.) 

In Abel, the history is constructed by sequence suffixing, using right append 
as the constructor in contrast to prefixing by means of left append. The history 
is always available for reasoning, as an abstract representation of the state, from 
which we can extract information. Consequently, the correct behavior of the 
specified object can be determined by a predicate. Choosing the prefix construc- 
tor instead would bring us to a recursive setting, similar to process algebras such 
as CSP. In this case, the history is not available for reasoning and information 
concerning the state must be passed along in process parameters that reveal 
parts of the internal structure of the program. An illustrative example here is 
the formalism CSP-OZ [20], which combines CSP with Object-Z. In this formal- 
ism, objects specified in Object-Z are represented as CSP processes by including 
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all attributes as process parameters. Abel specifications do not need to reveal 
the internal structure of the program, so they are in this sense more abstract 
than the corresponding process algebraic specifications. In particular, recursive 
definition of processes and the resulting fix-point semantics are avoided. 

Type simulation. In order to show that program code implements the intended 
specification, Abel uses type simulation techniques [12]. An abstract type sim- 
ulates a concrete type by means of an abstraction function. There are many 
techniques for type simulation. In Abel, focus has been on both strong simu- 
lation, where every function, and thereby every value, on the abstract type is 
simulated by a function on the concrete type, and on weak simulation, where 
concrete values at best approximate an abstract value, for instance giving room 
for capacity constraints at the concrete level. Type approximation corresponds 
to one possible method of data refinement. There is a rich literature on data 
refinement; for a recent overview, the reader may consult de Roever and Engel- 
hardt [18]. Although less standard, Abel’s refinement by type approximation 
reflects a profound concern for the practical applicability of formal methods. 

2.3 Explicit Object Identities 

In this section, we show how the formalism presented above can be extended 
in order to capture object interaction in systems with many objects. When we 
consider concurrent objects that communicate in parallel systems, an object 
may talk to several other objects. In this setting it is therefore not satisfactory 
to model the object’s behavior by its interaction with an implicit environment 
that consists of a single entity, as we did in the previous examples. Instead, 
we now consider the environment of an object as an unbounded set of other 
objects. When we specify an object in such a system, we will refer to this set 
as the object’s (communication) environment. For object systems, the history 
records communication between objects in the form of remote method calls. 
Therefore, we introduce object identifiers in the events that are recorded in the 
communication traces, so that every communication event contains the identity 
of the transmitting object. This lets us express properties that should hold for 
a single calling object, a particular calling object, or for all calling objects by 
projections on the history. Also, we can specify how calls from different objects in 
the environment are interleaved. We illustrate specifications with implicit object 
identities in communication events by an example, following [17]. 

Example 3: Consider an object controlling write access to some shared data 
resource. All objects in its environment are allowed to perform write operations 
on the shared data, but only one object at a time; we want to specify that write 
access is sequential. Assume that every event has an implicit sender identifier. 
Now, we can project traces on an object identifier to express projection on the 
set of all events associated with that identifier (ranging over operations) or on 
the name of an operation to express projection on the set of events associated 
with that operation (ranging over object identifiers). 
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Let OW represent (the completion of) an openjwrite operation, W a write 
operation, and CW a close-write operation. Let the predicate t prs Reg express 
that a trace t is a prefix of a trace in the regular language Reg. The prs predicate 
will be used to express invariant properties on the history. As before, Ti. denotes 
the history of communication events involving the current object. We denote by 
£ the current environment of the object we are specifying. 

interface SeqWrite [T : Type] 

begin 

opr OW 
opr W 
opr CW 

inv n prs [OW W* CW]* A Vo G £ : {H/o) prs [OW W* CW]* 

lemma : 0 < jKH/OW) - jK^/CW) < 1 

end 

The regular expression ensures that write operations W are performed between 
an openjwrite operation OW and a close-write operation CW. We want the reg- 
ular expression to hold for every object in the environment so we quantify over 
object identifiers. The predicate Vo G £ : (H/o) prs [OW W* CW]* quantifies 
over objects in the environment. By projecting the history on events associated 
with every calling object, we consider the (pointwize) communication between 
the objects of the environment and the object of the interface. The predicate 
above therefore states that every object in the environment adheres to this be- 
havior. The other conjunct H prs [OW W* CW]* states that the full history 
of the object adheres to this behavior as well. This means that write operations 
only occur when ‘^{Ti / OW) — / CW) = 1, for every object in the environment, 

and the lemma follows. Therefore, at most one object in the environment can 
perform write operations with the given invariant. □ 

Observe that in this example, the specified object is passive because it only 
receives and never transmits calls. In order to specify objects that are active 
as well, we need to reason about events that are transmitted from the object 
(output) to different objects in the environment, so communication events need 
to be equipped with the object identities of both the sender and receiver. 

3 Object-Orientation and Openness 

In open systems software may be changed, interchanged, and updated. This 
makes program reasoning more difficult as old invariants can be violated by new 
software, and also static typing can be too restrictive. Although there are appli- 
cations where this does not seem to be a problem, it is interesting to see how and 
to what extent strong typing and incremental, textual, and compositional rea- 
soning can be combined with openness. Strong typing alone can ensure essential 
safety properties, such as providing limited access rights. We will here explore 
some possibilities for controlled openness within the object-oriented framework. 
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In order to solve the conflict between unrestricted reuse of code in subclasses, 
and behavioral subtyping and incremental reasoning control, we suggest to use 
behavioral interfaces as presented in the previous section to type object variables, 
and consider multiple inheritance at the interface level as well as at the class 
level. Interface inheritance is restricted to a form of behavioral subtyping [35], 
whereas class inheritance may be used freely. Inherited class (re)declarations are 
resolved by disjoint union. A class may implement several interfaces, provided 
that it satisfies the syntactic and semantic requirements stated in the interfaces. 
An object of class C supports an interface I if the class C implements I. 

Reasoning control is ensured by substitutability at the level of interfaces: an 
object supporting an interface I may he replaced by another object supporting I 
or a subinterface of I. Subclassing is unrestricted with the consequence that 
interface implementation claims are not preserved by subclassing. If a class C 
implements an interface I, this property is not always guaranteed by a subclass 
of C, as a method redefinition may violate semantic requirements of I. Therefore, 
implementation claims (as well as class invariants) are not in general inherited. 

Strong typing. We consider typing where two kinds of variables are declared; an 
object variable by an interface and an ordinary variable by a data type. Strong 
typing ensures that for each method invocation o.m{inputs; outputs), where I is 
the declared interface of o, the actual object o (if not nil) will support I and the 
method m will be understood, with argument types “including” the types of the 
actual ones. Inclusion is defined as the pointwise extension of the subtype and 
subinterface relation, using co- and contravariance for in- and out-parameters, re- 
spectively. Explicit hiding of class attributes and methods is not needed, because 
typing of object variables is based on interfaces and only methods mentioned in 
the interface (or its super-interfaces) are visible. 

Modifiability. An obvious way to provide some openness is to allow addition of 
new (sub)classes and new (sub)interfaces. In our setting, this mechanism in itself 
does not violate reasoning control, in the sense that old proven results still hold. 
Also, additional implementation claims may be stated and proved. However, old 
objects may not use new interfaces that require new methods. 

A natural way to overcome this limitation is through a dynamic class con- 
struct, allowing a class to be replaced by a subclass. Thus a class C may be mod- 
ified by adding attributes (with initialization) and methods, redefining methods, 
as well as extending the inheritance and implements lists. (In order to avoid 
circular inheritance graphs, C may not inherit from a subclass of C.) Unlike 
addition of a subclass of C, all existing objects of class C or a subclass be- 
come renewed in this case and support the new interfaces. Reasoning control is 
maintained when the dynamic class construct is restricted to behavioral subtyp- 
ing, which can be ensured by verification conditions associated with the class 
modification [43]. Unrestricted use of the dynamic class construct, which may 
sometimes be needed, has the impact that objects of class C may violate behav- 
ior specified earlier, and constraints on compositions involving objects of class 
C must be reproved (or weakened). 
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Notice that as a special case of class modification, one may posteriorly add 
super-classes to an established class hierarchy. This would be an answer to a ma- 
jor criticism against object-oriented design [21], namely that the class hierarchy 
severely limits restructuring the system design. 

The run-time implementation of dynamic class constructs is non-trivial [36], 
even typing and virtual binding need special considerations: 

— The removal of a method or attribute from a class C violates strong typing, 
since such a method or attribute may be used in an old subclass of C and 
by strong typing the method or attribute must exist. This indicates that 
removal of methods or attributes should not be allowed. 

— A modified class C may add an attribute or a method m and thereby an 
old subclass D inherits m. The subclass may also inherit m (with the same 
parameter types) from another superclass of D. An implication is that the 
virtual binding mechanism must give priority to the old m, otherwise objects 
of class D will behave unpredictably and reasoning control is clearly lost. 
This can be implemented by a table associated with each class at run-time, 
updated whenever a superclass is modified. 

— The typing and well-formedness of a modification of a class C should not 
depend on any existing subclass of C. Consider the case where a new method 
m is added to a class C. This should be legal even if a subclass D already 
has a method m. The parameter types may well be the same, and this case 
predicts that we must accept unrestricted method redefinition in a subclass! 

— Parameter types may be only slightly changed in class C (say, only for the 
out-parameters of a method m), in which case we must tolerate arbitrary 
overloading in a subclass. Invocations of m on objects of a subclass D must 
respect old behavior, otherwise these objects will behave unpredictably and 
reasoning control is lost. An implication is that the virtual binding mecha- 
nism must give priority to local methods (that include the actual parameter 
types) over inherited ones. 

These implications give independent justification for declaring interfaces for ob- 
ject variables, while allowing unrestricted subclassing. In the next section, we 
consider specification and reasoning with behavioral interfaces more closely. 

4 Viewpoints to ODS 

In ODS, we can represent components by (collections of) objects that run in 
parallel and communicate asynchronously by means of remote method calls with 
input and output parameters. Often, such objects are supplied by third-party 
manufacturers unwilling to reveal the implementation details of their design. 
Therefore, reasoning about such systems must be done relying on abstract spec- 
ifications of the system’s components. We find specification in terms of observ- 
able behavior particularly attractive in this setting and imagine that components 
come equipped with behavioral interfaces that instruct us on how to use them. 
Furthermore, as a component may be used for multiple purposes, it can come 
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equipped with multiple specifications. This section presents a formalism for rea- 
soning about object viewpoints in the setting of ODS, extending the formalism 
of Section 2. Further details about this work can be found in [29,28,43]. 

4.1 Semantics 

We now propose a formalization of viewpoint specifications for objects commu- 
nicating asynchronously by means of remote method calls, restricting ourselves 
to safety aspects. Let Objects and Mtd be unbounded sets of object identifiers 
and method names, respectively, and let Data be a set of data values including 
Objects. Denote by List[T] the lists over a type T (and by [] the empty list). 

Definition 1 (Communication events). A communication event is a tuple 
{oi, 02 , m,t, inputs, outputs) such that 01,02 G Objects, oi yf 02, m G Mtd, 
t G {i,c}, inputs, outputs G List [Data], and t = i ^ outpmts = [ ]. 

Intuitively, we can think of these events as initiations and completions of 
calls to a method m provided by an object 02 by another object oi. Initiation 
events have no output. Communication is asynchronous as other events can be 
observed in between the initiation and completion of any given call. (We here 
assume strong typing, so the number and types of input and output parameters 
are correct by assumption in the events.) 

Definition 2 (Alphabet). An alphabet for a set of objects O is a set S of com- 
munication events such that {oi, 02 ,m,c,ins,outs) G S' {oi, 02 ,m,i,ins,[]) G 
S and (oi, 02, . . .) G S (oi G O A 02 ^ O) V (02 G O A Oi ^ O). 

At the specification level, the alphabet of an object supporting an interface 
is statically given by the interface. Denote by h/S and h \ S the restrictions of 
a sequence h to elements of the set S and to the complement of S, respectively. 

Definition 3 (Trace set). A trace set over an alphabet a is a prefix-closed 
set of sequences t G Seq[o;] such that, for every sequence t in the set and every 
completion event {oi, 02 ,m,c,inputs,outputs) G a, 

tt(t/ (oi, 02, TO, i, inputs, [])) > tt(t/ (oi, 02, to, c, inputs, outputs). 



Definition 4 (Specification). A specification F is a triple {0,a,T) where (1) 
O is a set of object identities, O C Objects, (2) a is an infinite alphabet for O, 
and (3) T is a prefix-closed subset o/Seq[o;]. 

We call O the object set of the specification F, a the alphabet of F, and 
T the trace set of F. In shorthand, these are denoted 0{F), a(F), and T{F), 
respectively. For a specification F, we can derive a communication environment 
S{F) of objects communicating with the objects of F, from 0{F) and a(F). 
In an ODS setting, we generally think of the communication environment as 
unbounded. If the object set of a specification D is a singleton {o}, we say that 
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r is an interface specification (of o). A component specification may comprise 
several objects. 

In order to increase readability, we will henceforth represent an initiation 
event (oi, 02 , m, i, [ii, . . . , i„], [ ]) visually by 0 i^ 02 .TO(ii, . . . , i„) and a comple- 
tion event {oi, 02 ,m,i, [ii, . . . ,i„], [?;i, . . .,Vp\) by 0 i^ 02 .m(ti, . . . ,i„;vi, . . .,Vp). 

Example J^: Consider the specification SeqWrite from Example 2.3, which we 
now reformulate as an interface specification of an object o. Let £ = {x £ 
Objects I X yf 0 } and let Data be a set of data values. The specification only 
considers one object, so 0(Seq Write) = {o}. The write method W has an input 
parameter ranging over Data. The alphabet of SeqWrite is now 

o;(Seq Write) A {x->-o.OW{),x^o.OW{),x—>-o.CW{),x^o.CW{) |x G £} 
U{x—>o.W {d),x^o.W {d)\x € £ A d € Data}. 

Controlled write access is obtained by restricting the possible traces of SeqWrite. 
For this purpose, we use patterns, i.e. regular expressions extended with a bind- 
ing operator •, and extend the prs predicate accordingly. Define a pattern 
W cycle by 

[[x^o.OWi) x<— o.OW() 

[[x^o.W{d) x^o.W{d)] •da Data]* 
x^o.CWf) x<— o.C'WO] • X a £]. 

The trace set is now specified by a prefix of the pattern: 

T(Seq Write) A }h : Seq[a(Seq Write)] | h prs Wcycle*}. 

Here, x is bound for each traversal of the loop and this binding operator on calling 
objects ensures sequential write access. A caller may perform multiple write 
operations once it has access. Note that a set defined by a predicate h prs R is 
always prefix-closed and that T(Seq Write) is a trace set. □ 

Refinement. Refinement describes a correct transformation step from specifica- 
tions to programs, usually by making the specification more deterministic in the 
sense of model-inclusion. In our setting of partial specifications, a step towards 
realization of the specification may involve considering additional communica- 
tion events, suggesting that refinement in our case must be after projection. 

Definition 5 (Refinement). A specification E' refines another specification 
r, denoted E' C E, if (1) 0{E) C 0{E'), (2) a(T) C a(T'), and (3) Vt G 
T(r') : t/a(T) G T(T). 

Using projection as suggested here, dynamic class extension (Section 3) is 
well-behaved with respect to refinement: the new extended class refines the old 
class. When considering liveness, the refinement relation must be extended to 
exclude additional deadlocks in a refinement step (cf. Section 7). 
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Composition. When two viewpoint specifications are composed, they synchro- 
nize on common events. However, as our focus is on the observable behavior of 
the specifications, internal communication between the objects of the composed 
specification is hidden. 

Definition 6. The internal events of a set S of objects are all communication 
events between objects of the set, T{S) = ^^gg{(oi, 02 , . . .), ( 02 , oi, . . .)}. 

We will write T{r) instead ofX{0{r)). As we consider component viewpoints 
here, events that are internal in one specification may be observable in another. 
We say that two specifications are composable if this is not the case [29,28]. 

Definition 7 (Composition). Let T and A be composable component specifi- 
cations. Then r\\ A is the specification (0,a,T) where (1) O = 0{T)[J0{A), (2) 
a = a(r)Ua(A)-I(C>), and (3) T A {h/a \h/a{T) G T{T) A h/a{A) G T(A) }. 



4.2 Behavioral Interfaces 

Clearly, the specifications of Section 4.1 can be given a syntax a la Abel. In this 
section, we consider such a treatment for interface specifications in a generic 
manner. These specifications are behavioral interfaces; they can be supported 
by different objects. An interface can be implemented by different classes and a 
class can implement different interfaces. An interface has the following syntax: 

interface F [(type parameters)] ((context parameters)) 
inherits F\, F 2 , ... , Fm 
begin 
with G 

opr mi(. . .) 



opr m„(. . .) 

asm jformula on local trace restricted to one calling object^ 
inv jformula on local trace/, 
where jauxiliary function definitions/, 

end 

Interfaces can have both type and context parameters, the latter typically 
describes the minimal environment representing static links needed by objects 
that support the interface. An initiation and a completion event is associated 
with each method declaration (ranging over method parameters). In the inter- 
faces, we use the keyword “this” to denote the object supporting the interface 
and “called’ to denote an object in the environment. We shall now briefly con- 
sider the remaining parts of the syntax, for technical details and discussion the 
reader is referred to [29,43]. The use of interfaces for specification purposes is 
illustrated by way of examples in Section 5. 
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Assumption guarantee predicates. In ODS, the environment in which an object 
exists is subject to change and specifications are relative to an assumed behav- 
ior of the environment. Hence, we use the assumption guarantee specification 
style [32], but we adapt it to our setting of observable behavior. Assumptions 
are the responsibility of the objects of the environment; therefore, assumption 
predicates consider traces that end with input to the current interface and only 
communication with a single object in the environment. An assumption predicate 
A{x, y, h) ranges over objects x in the environment, supporting objects y, and 
traces h. Let o) and out(/i, o) denote functions that return the longest pre- 
fix of a trace h ending with an input or output event to an object o, respectively. 
If A is an assumption predicate, define A*”(x, /i) = Vo G £ : A{o, x,in{h, x)) 
and /i) = Vo G £ : A(o, x, out(/i, x)). Invariants are the responsibility of 

the object supporting the interface; they are guaranteed when the assumption 
holds and consider traces that end with output from the current interface. If 
I{x, h) is an invariant predicate ranging over supporting objects x and traces h, 
define /i) = /(x, out(/i, x)) A A°“*(x, /i). The trace set T(T) of a specifi- 

cation r with assumption predicate Ap and invariant predicate Ip is the largest 
prefix-closed subset of {/i G Seq[o;(r)] | Aft (this, h) Ip^*(this, h)}. 

Inheritance. Multiple inheritance is allowed for interfaces, but cyclic inheritance 
graphs are not allowed. If an interface F is declared with an inheritance clause, 
the alphabets of the super-interfaces are included in the alphabet of F and the 
traces of F must be in the trace sets of the super-interfaces when restricted to 
the relevant alphabets. In the subinterfaces, we can declare additional methods 
and behavioral constraints. An interface will always refine its super-interfaces. 

Mutual dependency. Because objects are typed by interface, we can specify that 
only objects of a particular interface (a cointerface) may invoke the methods of 
the current interface, using the keyword with. Furthermore, the current inter- 
face knows the methods of the caller visible through the cointerface. This gives 
strong typing in an asynchronous setting. Semantically, a cointerface declaration 
changes the alphabet of the current interface as the communication environment 
is reduced whereas new methods of the caller are added. 

5 Case Study: the Software Bus 

In this section, we illustrate the use of interface specifications to capture view- 
points concerning the dynamic nature of a software bus, a communication plat- 
form to which processes may register in order to share data and resources. (This 
is a stripped version of an actual system used for monitoring nuclear power 
plants, more details on the software bus and its specification can be found in [31] .) 
We consider a distributed architecture for the software bus, with a portmapper 
and a collection of data servers. The general lay-out of the software bus is shown 
in Figure 1. Processes may connect (and disconnect) to any data server. The 
task of the portmapper is to manage registration of processes, and communi- 
cate information about processes to other processes, via their data servers. Data 
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Fig. 1. Decomposition of SoftwareBus. Data servers have an interface 
SBJData available to other data servers and an interface SB_Connections 
available to the portmapper. The portmapper offers an interface 
SB JPortmapper to data servers. 



servers communicate with each other in order to share data processing tasks, 
on behalf of their processes. These tasks include the creation of variables, the 
assignment of values to variables, accessing the values of variables, and destroy- 
ing variables. The software bus system is object-oriented: classes, functions, and 
variables are treated as software bus objects, i.e. as manipulatable data in the 
software bus system. An object in the system is identified either by reference or 
by a name and a reference to its parent. For specification purposes, we identify 
two types; Name for object names and Ref for object references. The latter 
will have subtypes, among them we find ParentRef for parent objects and 
AppRef for application processes. We shall now specify a data server interface 
SB JData for manipulation of data, a data server interface SB_Connections 
for updating information on remote applications, and a portmapper interface 
SB_Portmapper. 



5.1 Communication between Data Servers 

The interface SB JData considers methods for object manipulation between data 
servers in the SoftwareBus. For brevity, we will here only consider two such 
methods: 

opr id ( in name: Name , parent_ref: ParentRef ; out obj_ref: Ref ) 
opr deLobj ( in obj_ref: Ref ) 

Intuitively, the method id obtains the reference to an object at a remote server 
and deljobj deletes an object at a remote server. It is assumed that a data server 
only attempts to delete an object to which it has obtained a reference (via id). 
If the object is already deleted by another remote server, the method call will 
not be completed (until the reference has been recreated). We here denote by 
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Sr the set of events that can be associated with a given reference r, Sr = {x^ 
y j, r) , x^y .del -obj (r) , x^y .del -obj (r) \x,y € Objects}, ignoring irrelevant 
parameters by underscore. The assumption can be formalized as follows: 

Ad{x, y, h) =\/r G Ref : 

h/Sr prs [[x^y.id{.,j,r)] + 

x^y.del-obj (r) x^y.del-obj (r)]* 

The invariant is concerned with output from the current object, in this case 
completion events to the methods id and deLobj. The assumption above states 
that a data server will wait for the completion of a call to the current data 
server before making new calls to this server. We check if there is a pending call 
to del-obj{r), using a predicate pending: 

pending{mtd,x,y,h) = h / {x^y .mtd{. . .) , x^y .mtd{. . .)} 

G [x^y.mtd{. . .),x^y.mtd{. . .)]* x^y .nitd {. . .) 

As we ignore object creation in this example, we assume that an object exists 
once it has been assigned a reference in a call to id. Considering the entire history 
of a data server (seen through the SB_Data interface), we can identify traces 
after which we believe that a reference is to an existing object: 

^ exists{r, e) 

exists{r, h h x^y.del-obj(r)) 
exists{r, h h x^y.id{-, r)) 

exists{r, h h others) = exists{r, h) 

In this definition, cases are in the considered order and ‘/i h others’ handles the 
remaining cases. The invariant Id{h, x) expresses that pending calls to del-obj{r) 
are only completed when the object with reference r is known to exist: 

Id{x, e) = true 

Id{x, h h y^x.del-obj{r)) = pending{deljobj, y, x, h) A exists{r, h) 

Id{x, h h others) = true 

Remark how the case distinction with ‘others’ allows us to ignore irrelevant 
events in the above predicates. This way, the predicates can be given in a com- 
pact, readable format when only a few events of an alphabet need to be consid- 
ered. Also, this predicate format facilitates reuse of the predicates in interfaces 
with extended alphabets, typically in subinterfaces. 

We now define the interface SB JData (types for method parameters are as 
given above). 

interface SBJData 
begin 

opr id ( in name, parent_ref; out obj_ref ) 
opr deLobj ( in obj_ref ) 
asm Ad{caller, this, h) 
inv Id (this, h) 

end 
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This interface does not consider calls to other servers. The next step is to 
let SB_Data be inherited by a new interface SB_DataAct, which includes 
SB_DataAct as a cointerface and Vo G E : Ad{this,o, h) as invariant. 

5.2 Communication with the Portmapper 

In this section, we consider communication between the portmapper and the 
data servers. First, we specify an interface of the data server, which offers a 
method going-down to portmappers: 

interface SB_Connections 
begin 

with SB_Portmapper 

opr going_down( in ref: AppRef ) 
asm true 
inv true 
end 

By declaring SB_Connections to be a cointerface of SB .Portmapper, the 
interface of the portmapper, the events associated with going-down are included 
in the alphabet of SB_Portmapper and we can specify the actual use of the 
method there. The method will be used to signal that applications in the envi- 
ronment are about to leave the SoftwareBus. When an application enters the 
software bus, its (current) data server will register it with the portmapper, and 
when it exits, likewise. Furthermore, a data server may contact the portmap- 
per in order to know if (and where) an application is currently registered. The 
associated methods are 

opr init ( in name: Name ) 
opr exit (in name: Name ) 

opr conn_app ( in appljiame: Name ; out applj:ef: AppRef ) 
opr disc_app ( in applj-ef: AppRef ) 

Intuitively, init signals that an application enters the system, exit signals that 
an application leaves the system, conn-app establishes a logical connection to 
appl-name, and disc-app disconnects the logical connection to appl-ref. Obvi- 
ously, logical connections should only be disconnected after having been estab- 
lished, which we formalize by the predicate 

conns{x, y, h) =\/r G AppRef \ h/r prs [x^y.conn-app{-; r) 

x^y . disc-app(r) x^y . disc-app ( r ) ] * 

Furthermore, logical connections and disconnections from an application x may 
only occur when x is registered with the portmapper y. 

is-reg{x,y, h) = 

h/x prs x^y.init{x) x^y.init{x) 

[x^y.conn-app{-) \ x^y.conn-app{-; _) 

I x^y .disc-app{-) \ x^y.disc-app(-)]* 
x^y.exit{x) x^y.exit{x) 
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The portmapper assumes that all data servers adhere to this behavior, so define 
its assumption by the formula 



y, h) = isjreg{x, y, h) A conns{x, y, h). 

The invariant of SB_Portmapper considers when output from the portmap- 
per should occur. For this purpose, we determine if an application is currently 
registered in the system by a predicate up on the history: 

~^up{x,y,e) 

up{x, y,h\- z^y.init{x)) 
up{x, y, ft. F others) = up{x, y, ft) 

Similarly, we determine if an application oi has an established logical connection 
to another application 02 via the portmapper p after history ft by the predicate 
comi-up{ai,a2,p, ft): 



^ connjup{ai,a2,p, s) 

conri-up{ai,a2,p, ft F ai^p.connjipp{a2)) 

^ connjup{ai,a2,p, ft F ai^p.disc-app{a2)) 

^ connjup{ai,a2,p, ft F p^a\. going -down{a2)) 
connjup{ai,a2,p,h F others) = connjup{ai, 02, p, h) 

We consider a logical connection closed (or broken) if oi gets a notification from 
the portmapper that going jlown{a2)- (The events associated with this method 
come from the cointerface.) We use the abbreviation notified{n,p,h) below for 
the the predicate Va G AppRef : ^ connjup{a,n,p, ft) and define the invariant 
of SB .Portmapper as follows: 

(P; ^) 

Ipm{p, ft F a^p.init{n)) = 

^ up{n, _, ft) A pending{init{n) , p, a, ft) A Ipm{p, ft) 

Ipm{p, ft F p-^a. going jlown{n)) = 

conn-up{a, n,p, ft) A pending{exit{n) , p, _, ft) A Ipm{p, ft) 

Ipm{p, ft F a^p.exit{n)) = 

up{n, _, ft) A notified{n,p, ft) A pending{exit{n) , p, a, ft) A Ipm{p, ft) 
Ipm{p, ft F a^p.conn-app{n, r)) = 

^ connjup{a, n,p, ft) A pending{connjipp{n),p, a, ft) A Ipm{p, ft) 

Ipm{p, ft F a^p.disc-app{n)) = 

connjup{a, n,p, ft) A pending{discjxpp{n) , p, a, ft) A Ipm{p, ft) 

Ipmip, ft F others) = Ipm{p, ft) 

The invariant allows for asynchronous calls to the portmapper, as other events 
may occur between the initiation and completion of any given call. In particu- 
lar, the invocation of exit explicitly results in calls from the portmapper. The 
SB J*ortmapper interface is now specified (types for method parameters are 
as given above). 
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interface SB_Portmapper 
begin 

with SB_Connections 
opr init( in n ) 
opr exit( in n ) 
opr conn_app( in n; out r ) 
opr disc_app( in r ) 
asm Apm,{caller, this, h) 
inv I pm (this, h) 
end 



5.3 Internal Behavior of the Data Server 

In this section, we consider how the two interfaces of the data servers can be 
combined in order to give a more complete specification of the data server in an 
interface SB_DataServer. In particular, we want to express that a data server 
can only make calls to another data server when it has an established logical 
connection to that data server. For convenience, we inherit auxiliary predicates 
as well as the semantics through interface inheritance. 

This interface considers calls made by the current object, so we will strengthen 
the invariant of the data server (which we presently perceive as the conjunction 
of its two interface invariants, restricted to appropriate projections on traces). 
Define 

Ids(x,s) 

Ids(x,h h x^y.id(J)) = connjup(x,y,p,h) A Ids(x,h) 

Ids(x, h h x^y.deLobj(_)) = conn.up(x, y,p, h) A Ids(x, h) 

Ids(x, h h others) = Ids(x, h) 

The interface SB_DataServer can now be specified by 

interface SB_DataServer 

inherits SB_Connections, SB_Data 
begin 

inv Ids (this, h) 

end 

By definition, any data server with the SB_DataServer interface will also 
support the two super-interfaces SB_Data and SB_Portmapper. At the se- 
mantic level, super-interfaces are always refined by their subinterfaces. 

6 Composing Assumption Guarantee Specifications 

Just as multiple inheritance lets us combine interfaces that are supported by the 
same objects, we can compose specifications where this need not be the case. 
Definition 7 of Section 4.1 defined composition semantically. In this section we 
consider a composition rule for specifications made in the assumption guarantee 
style of interfaces, thus a specification F is on the form 

{0(F),a(T),{h G Seq[a(F)]|A)7(/i) ^ /r‘(/i)}), 
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where Ap and Ip are the assumption and invariant predicates associated with 
r. The supporting objects are here given by 0{r), the functions in(/i) and 
out (ft,) return the longest prefix of ft that ends with input or output to any 
object in 0{r), respectively. Let F + A denote the syntactic composition of two 
specifications F and A. We want to derive an assumption A and an invariant I 
that describe the traces of T + Z\ from the predicates of F and A. 

Composition should encapsulate internal communication, so the commu- 
nication environment E{F + A) excludes objects from the object sets 0{F) 
and 0{A). Therefore, for the object set, communication environment, alpha- 
bet, and internal event set, we follow the semantics (Definition 7) and de- 
fine 0{F + A) A 0{F\\A), S{F+A) A S{F\\A), a(T -h A) A a(T||A), and 
F{F -I- A) A F[F\\A). Let ft G Seq[o;(r -I- A)]. Now, define an assumption predi- 
cate for T -I- A by 

A“(ft) A A“(ft/a(L)) A A^{h/a{A)) 

= Vo' G £ : Ap{o, in(ft/o)) A Aa{o, in(ft/o)). 

Due to the quantification over objects in the environment, we have that Ap(h) 
Ap{h\T{F + A)). However, the assumption A^'^{h) above is not strong enough 
to guarantee either of the invariants Ip and I a, because nothing has been as- 
sumed with regard to the internal communication between objects of the two 
specifications. This leads to the proof conditions (1) and (2) below. 

In contrast to the assumption, the invariant does not quantify over the objects 
of the environment. Therefore, we cannot derive an invariant / directly from the 
invariants of F and A by removing internal communication; we need to consider 
the full alphabet. Let ft G Seq[o;(r) U o;(A)]. We first define the basic invariant 
/ of the composition by 

Jbasic(;j) A /^(out(ft/a(T))) A (out (ft/«( A))) A A°“*(ft). 

However, the basic invariant predicate takes internal events into account. It is 
well-known that hiding corresponds to the introduction of existential quanti- 
fiers [1]. For the invariant, we extend the alphabet of T -|- A with the hidden 
internal events, and hide the extension inside an existential quantifier. Without 
inherited specifications, the derived invariant is 

r“*(ft) A 3ft' e Seq[a(F) U a(A)] : ft = ft' \ X(T + A) A /^"""(ft'). 

Inheritance. We will assume that specifications can inherit other specifications 
like the interfaces of Section 4. Say that a specification F inherits another spec- 
ification S. At the semantic level, inheritance is interpreted as refinement: for 
all traces h G T (F), we have that ft/o;(S) G T{U). At the syntactic level, inheri- 
tance restricts the set of possible traces ft defined by the assumption and invari- 
ant predicates by additional conjuncts of the form A“(ft/a(S)) Ip{h/a{T,)). 

However, in the composition F + A, these additional conjuncts are only valid 
for the extended trace, so they must be placed inside the existential quantifier 
of the invariant. (Due to hiding, it is not the case that F + A directly inherits 
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the super-interfaces of F and A.) Therefore, considering inheritance, we define 
the invariant of a composition as follows. 

Definition 8. For any specification S, we denote by As and Is its assumption 
and invariant predicate, respectively. Consider two specifications F and A and 
denote by Si, , Sn the specifications inherited by either F or A. The invariant 
of the composition F + A is defined as 

r^\h) = 3h' G Seq[a(T) U a(A)] : h = h' \ I{F + A) A 

(Vz G {1, . . . ,n} : JT£^{h'/a{Si)) =A Ifjf{h'/a{Si))) A 

with the associated proof conditions 

Wh G Seq[a(T)] : A IfT*{h)) ^ A^l{h/F{F + A)) and (1) 

V/i G Seq[a(A)] : {A^ff{h) A lT{h)) =A A^P{h/F{F + A)). (2) 

In order to maintain reasoning control for F + A, output from F should not 
break the assumption of A and vice versa. The proof conditions (1) and (2) en- 
sure that the internal communications of T-|- A respect the assumptions Ap and 
A/i of the two component specifications F and A. Circularity in compositional 
proofs is avoided because assumption predicates concern traces that end with 
input whereas invariants concern traces that end with output. 

With the assumption and invariant predicates derived for T -|- A, we define 
the trace set T{F -I- A) as the largest prefix-closed subset of 

{h G Seq[a(T + A)] | o) ^ 

6.1 Soundness of the Composition Rule 

In this section, the proof rule for composition is shown to be semantically sound, 
i.e. that any trace in the semantically defined composed specification is included 
in the trace set obtained through the proof rule: T{F\\A) C F{F + A). This 
corresponds to the notion of soundness for regular verification systems, see for 
instance Apt and Olderog [4]. Here, the soundness proof relies on the distinction 
between input and output events; when we consider communication between 
two objects, input to one is output from the other, so we can reason inductively 
about the communication traces between the two objects. The proof extends a 
proof made by Dahl and Owe [17] for a somewhat simpler formalism. 

Proof. Let F, A, Si, . . . , Sn (where n > 0) be (component) specifications such 
that every Si is inherited by either F or A. Assuming that the proof conditions 
(1) and (2) hold, we now show that T(T||A) C T(T + A). Observe that, for 
any h G F{F -I- A), if one of Ap{h/a(T)) and Ap{h/a{A)) does not hold, 
neither does A^^{h). Now, consider a trace h G Seq[a(T) U Q!(A)] such that 
h \ F{F + A) G F{F + A). By assumption, for any such trace h, we have that 

A^p{h/a{T)) ^ I'fAph/aiT)), and 
Ap{h/a{A)) ^ IfP\h/a{A)). 



( 3 ) 

( 4 ) 
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We must show that if A^'^{h\I{r +Z\)) holds, then I{h\X{r +Z\)) also holds. The 
proof is by induction over h, but we show a somewhat stronger result, namely 

Vh : Seq[a(T) U a(A)] : 

Vz G {1, . . . ,n} : ^ (/r/«(Si)) ... 

Al'P^*{h/a{T)) A r^*{h/a{A)) 

AAr{in{h/J{r + A))) A AA{in{h/J{r + A))), 

from which the invariant follows. Two observations are in order at this point. 
First, due to quantification over the objects of the communication environment 
in assumptions, + A)) entails 

\ I{r + A)/a(r)) A \ J{r + A)/a(A)). (6) 

Second, inheritance graphs are acyclic, so we can inductively assume soundness 
for inherited specifications. Once we have established and we get 

A*^^(/i/a(Si)) ^ I|;f (/i/a(Si)) for 0 < i < n. (7) 

We now proceed with the proof. As we are dealing with safety properties, 
the formula (5) holds for the empty trace e. Next, consider the induction step. 
We assume that (5) holds for a trace h and show that it holds for h\~ m, where 
m G o;(r) U a(A). Assume first that m G a(F + A), such that A™{h h m). The 
induction hypothesis gives us 

Ar(in(/i h m/X{r + A))) = Ar{m{h/X{r + A))) and 
AA{in{h h m/X{r + A))) = AA{in{h/X{r + A))), 

so by observation (6), both A^p{h h m) and A^^{h h m) hold. Then, by obser- 
vations (3) and (4), the invariants 

h m)/o;(r)) and 
m)/a(A)) 

hold and by (1), (2), and (7), we can conclude that (5) holds for h\- m. Now, 
assume that m G X{X + A). We have four possibilities. If we consider two object 
identifiers oi and 02 such that oi G 0{X) and 02 G 0{A), these possibilities are 
0 i^ 02 .m(. . .), oi^ 02 .m(. . .), 02 ^oi.m(. . .), and 02 ^ 0 i.m(. . .). In the first case, 
m is the initiation of a method m in 02 by oi. But then the event is an output 
event for X and hence, the assumption of X holds by the induction hypothesis: 

Ar{in{{h h m)/X{X + A)))=Ar{in{h/X{X -h A) h m)) 

=Ar{in{h/X{X + A))). 

Consequently, by observation (6), the assumption A^p{h h m) of specification X 
holds. Therefore, by assumption (3), the invariant h m) of specification 

X holds. Now we know that both the assumption and invariant of X hold, so 
by proof condition (1), the assumption A/i(in(/i h m/X{X + A))) holds. Then, 
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by (6), we get the assumption of A and finally, by observation (4), the invariant 
I^*{h h m) holds. As we have established the invariants of F and Z\, observation 
(7) lets us conclude. 

In the next case, m = oi<— 02 .m(. . .) is an output event from specification A. 
Here, we first consider the assumption A/\ of A, which gives us: 

AA{m{h h m/I{r + Z\))) = AA{in{h/I{F + Z\))), 

as m disappears by projection. The predicate holds by the induction hypothesis. 
By similar reasoning to the previous case, we can now establish the invariants 
of r and A, and (7) gives us the result. The two last cases are similar to these. 



7 Discussion 

The main objective of this paper has been to show how Dahl’s notion of object- 
oriented specification can be extended for reasoning about open distributed sys- 
tems, as object-orientation is a natural paradigm for ODS [26,17]. In this section, 
we draw some lines to related work and suggest some future extensions to the 
work we have presented in this paper. 

Our approach is based on trace descriptions of (aspects of) the observable 
behavior of objects and components. Traces are well-known from the literature 
on processes, data flow networks, and modules [8,25,33,39,45]. These formalisms 
do not claim to be object-oriented and tend to be based on synchronous com- 
munication along channels, fix-point reasoning, and possibly infinite traces, in 
contrast to Abel’s approach. Object reference passing can be simulated using 
named channels instead of named objects, for example in the 7r-calculus [49], but 
using explicit object identifiers in the communication events allow a more natu- 
ral representation. Explicit object identifiers may be found in languages such as 
Actors [2] and Maude [9]. Both these formalisms also allow asynchronous com- 
munication, exchange of object identities, and a large degree of modifiability. 
However, they are specialized towards system modeling rather than develop- 
ment and reasoning control, lacking for instance refinement notions that capture 
correctness for system development and modification. 

We find specification in terms of observable behavior particularly attrac- 
tive for reasoning about open distributed systems, where implementation detail 
need not be available for (client) objects in the environment. On the contrary, 
such detail can be intentionally hidden, being the intellectual property of some 
third-party manufacturer. In this respect, our approach is related to coalgebraic 
formulations of object-orientation such as [27], in which a class specification has 
assertions that equate sequences of observations on objects of the class. In gen- 
eral these assertions consider the entire history of the object and the conjunction 
of assertions thus resembles Abel’s history invariant. However, the coalgebraic 
approach does not seem to allow the kind of dynamic class extensions we have 
considered here, as the objects are semantically defined in terms of their stat- 
ically given classes. Of course, state-based approaches may equally well supply 
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a specification of an abstract state that does not directly reflect the implemen- 
tation of a component. However, refinement becomes complicated when data 
structures change, in particular for aspects, described using different data struc- 
tures, and dynamic extensions, captured in our formalism using projection on 
traces. 

The idea of separation of concerns in specification seems to have originated 
with Parnas [44]. Partial specifications are perhaps best known for describ- 
ing typical case-scenarios in specification notations such as Message Sequence 
Charts and UML. However, it is unclear how different cases relate to each other 
through composition and refinement in these notations. The use of interrelated 
viewpoints is recommended for ODS by the ITU [26] and work on combining 
viewpoints in this setting has been based on e.g. Object-Z [19, 6] and timed au- 
tomata [5]. Two major differences between these approaches and ours are, first, 
that they are state-based whereas we prefer to model objects at an early stage by 
observations and, second, they are synchronous whereas we And asynchronous 
communication natural for distributed systems. Viewpoints as presented in this 
paper resemble aspects of aspect-oriented programming [34], describing aspects 
by their observable behavior as system services cross-cutting an object grid. 
Composition in our formalism corresponds to synchronization of aspects, which 
suggests a formalism for specification and reasoning about the development of 
aspect-oriented programs. Further investigation in this context is future work. 

Specifications using observable behavior let us describe objects in an abstract 
way, describing properties by extracting information from the history. Further- 
more, we can model object behavior in a constructive graphical way with trace 
patterns. From such graphical specifications, the step to implementation in a 
state-based guarded command language is straightforward. Much work has been 
done on developing useful graphical specification notations, for instance with 
Statecharts, Petri nets, and UML, and on their formalization. Interestingly, there 
is also work on graphical representations of formal notations, an example being 
Actor specification diagrams [47]. Our trace patterns try to visualize behavior 
and could perhaps be expressed graphically in a similar way. 

Finally, the formalism as presented here only considers safety specifications. 
In the context of open asynchronously communicating systems, liveness prop- 
erties are largely dependent on the environment, which we do not control. A 
weak form of liveness is to identify deadlock deterministic objects, i.e. objects 
where deadlock is not due to internal non-determinism. For deadlock determin- 
istic objects, we can to some extent reason about liveness properties by means 
of prefix-closed trace sets, without having to resort to a stronger apparatus in- 
cluding infinite traces, temporal logic, etc. We propose an incremental approach 
by including exceptions in the reasoning formalism through refinement, and in 
particular timeouts. Thus, we can reason about liveness properties of our own 
objects even when the environment is unstable. Initial research in this direction 
has been done in the context of fault tolerance [30], but more work remains. 
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8 Conclusion 

The term “object-oriented specification” was coined by O.-J. Dahl for a specifica- 
tion style where the internal implementation details of objects are encapsulated 
and behavior is expressed in terms of permissible observable communication. 
An object’s observable communication history represents an abstract view of its 
state, readily available for reasoning about past and present behavior. Using a 
(mythical) history variable, the behavior of an object is determined by its com- 
munication history up to present time. The approach emphasizes mathematically 
easy-to-understand concepts such as generator inductive function definitions and 
finite sequences, avoiding fix-point semantics and infinite traces. 

In this paper, we have shown how this approach can be extended in order to 
reason about open distributed systems. In particular, we consider objects run- 
ning in parallel, communicating by means of asynchronous remote method calls 
by which object identifiers can be exchanged. In accordance with the ITU [26], 
the approach supports partial specification by viewpoints, representing object 
behavior in behavioral interfaces. Openness appears in the formalism by allow- 
ing new (sub)classes, new interfaces for old classes, and a restricted form of 
dynamic class extension, while maintaining reasoning control. 
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Abstract. Although SIMULA was proposed in 1967 and in details de- 
scribed in 1968, it offers more than object-oriented programming. To- 
gether with object orientation, its process orientation and block orien- 
tation offers to model systems containing modeling elements. The devel- 
opment of this direction of application is described, concluding by the 
simulation of systems in that there are simulating computers that influ- 
ence those systems. The development goes through the nested modeling 
to the reflective modeling. Nested modeling uses models of the systems 
that contain elements using other models, while reflective modeling is 
a special case of nesting modeling, in which the elements of the mod- 
eled system use models of the system in which they occur. Simulation 
modeling appears the most important factor in that domain. 



1 Preface — Historical Introduction and Personal 
Reminiscence 

The 60-ies of the 20th century were the second entire decade when Czechoslo- 
vakia was a part of the Soviet block, i.e. when its life was in a totalitarian way 
governed from Kremlin. The instructions came in the Russian language. Only 
a few people know that it was the only one of the cultural languages, which 
had no term for computer simulation. A certain Russian term, which was in- 
tended to mean computer simulation and which could be translated into English 
as imitation modeling, was introduced not sooner than in the late 70-ies and 
came into common use only in the late 80-ies. In the 60-ies the governing forces 
seating in Kremlin were still under influence of the Stalinist ideology of refus- 
ing computers and although they did no more use slogans like “Cybernetic — 
pseudoscience of the obscurians” they understood the computing technique as 
an only auxiliary tool of mathematics, i.e. a tool for final (numerical) solution of 
mathematical entities that arose after a conventional analysis performed by pre- 
computer mathematicians. An iterative communication between a human and 
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a computer, which admitted a human to view the computer behavior as that 
of an experiment, and the human governing the computer as a deep rational 
mans reaction to the behavior of the computer, was behind the horizons of the 
totalitarian leaders of the East European science. Moreover, for the leading case 
of that attempt, i.e. for computer simulation, the same leaders of science met 
another drawback, namely the above mentioned absence of the term that could 
be applied in the centralized instructing in the East European science. Even in 
case the Kremlin bureaucrats had wanted to instruct the leaders of science in 
the satellite countries about the importance of computer simulation they would 
not be able to tell that. The persons in Czechoslovakia who were delegated by 
Kremlin to lead the development of science were old men without any contacts 
with the contemporary state of the sciences, they obeyed the Kremlin directives 
and were allusive and mistrust against the term (computer) simulation, consid- 
ering it with a suspicion that it could be something of ideological diversion, i.e. 
of the highly punished behavior in the totalitarian society. Computer simulation 
was far from being mentioned at the University courses and a small number of 
persons who had recognized its importance had to grow it almost illegally. 

In 1966 I entered the Faculty of General Medicine of Charles University in 
Prague to build there a computer laboratory in a department oriented to bio- 
physics and nuclear medicine. The specialists in medicine and biology, whom I 
met there, were at a high level of their profession and wanted to apply computers 
but they were perplexed by them, by algorithmization and by transforming their 
questions and problems into the physics of computing technique. But after a few 
weeks I watched them to have used a rather exact tool, namely compartmen- 
tal systems, i.e. systems composed of well stirred volumes of matter, connected 
by idealized channels able to let non-zero volume through, contrary to the fact 
that their volume is zero [1], [2]. I prepared (and during the following months 
implemented) a programming language that enabled the non-computer-oriented 
specialists to describe compartmental systems: the description used terms fa- 
miliar to the common terminology of the compartmental systems practice and 
a compiler processed it to a computer program that generated data similar to 
those that could be measured at a real compartmental system [3]. 

Charles University printed a booklet [4] on the mentioned software prod- 
uct and distributed it abroad. The coming political relaxation of the so called 
Prague Spring caused a short independence of the Czechoslovak science on the 
control from Kremlin and that situation enabled such international activities 
and the events that followed: the booklet came also to Ole-Johan Dahls hands, 
who prepared the famous IFIP Working Conference on Simulation Program- 
ming Languages (May 1967 in Oslo). The conference must be really understood 
as famous, because O.-J. Dahl and K. Nygaard presented there the principles 
of language SIMULA 67, i.e. the principles that were many years later recog- 
nized as leading principles of the development of programming and knowledge 
representation and called object-oriented programming. O.-J. Dahl invited me to 
come to the conference and to present there my software product. So I learned 
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that I practiced simulation and that I designed and implemented a simulation 
language. 

I returned from the conference with a joyful intention to throw out my soft- 
ware product and to use SIMULA 67: in my consideration it appeared as an 
ideal tool for solving not only high problems of programming, modeling, simu- 
lation and knowledge representation, but also everyday obstacles, rooting in the 
general phenomenon that making a program in a certain professional domain 
stimulated immediate demands for its author to make further programs belong- 
ing to the same domain or to a kindred one. My information about SIMULA 
principles were positively accepted by some Czechoslovak specialists and several 
years later SIMULA implementations appeared at certain main frame comput- 
ers like CDC Cyber, IBM 370 and its East European copy called JSEP 1040. 
The mentioned specialists met at seminars organized under the Czechoslovak 
Cybernetic Society in its Working Group of SIMULA Users. I informed about 
SIMULA also during my lectures taken at Charles University in Prague and 
later at new Czech Universities established in Ostrava and in Pilsen. 

2 First Directions in SIMULA Applications in 
Czechoslovakia 

In the seventies, the Czechoslovak specialists applied SIMULA as a powerful 
simulation tool in some domains like steel metallurgy, machine production, agri- 
culture, services, computer design, nuclear power plants, internal logistic of fac- 
tories, medicine and ecology. In a smaller extent, SIMULA was also used outside 
simulation, like in musical science (analysis and synthesis of melodies and poly- 
phonies, dodecaphonic music theory), in airplane production scheduling and in 
system optimization. 

All those applications did not overpass the conventional view to general sys- 
tems, that was interpreted by the habitual scheme of class nesting used by every 
SIMULA user: one class (called main class), representing a certain world viewing 
(or a problem oriented language fully defined in SIMULA, or a formal theory de- 
fined in SIMULA) contained other classes (let us call them elementary classes), 
representing the concepts applied in that world viewing (or in that problem ori- 
ented language or in that formal theory). A block prefixed by the main class 
represented a pattern of a model: when the computing process entered into such 
a block a new model arose and when the computing process left the block the 
model disappeared. If the main class introduced a simulated time axis the time 
flow arose and disappeared together with the model. A cycle containing such a 
block represented a simulation study, i.e. a sequence of simulation experiments 
so that each of them had its own time flow, which was not bound with those of 
the other experiments. 

Already in that phase of SIMULA applications we realize that the block ori- 
entation of SIMULA allows class nesting: inside the main class (for example class 
geometry on page 168) other classes were nested (for example classes point, 
line, circle etc.). 
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class geometry; 

begin class point(x,y); real x,y; . . . ; 
class circle(center , radius); 

ref (point) center; real radius; ... ; 
class line( . . . ) ; ... ; 
ref (point) 0; ref (line)x_axe,y_axe; 

0 : -new point (0,0); 

x_axe : -new line (...); y_axe : -new line (...); 

end of geometry; 

We did not met anything similar later, when we studied other object-oriented 
programming languages (C-|— 1 -, SmallTalk, Eiffel etc.), which were presented 
to the world professional community. Main class seemed being nearer to the 
modeled world than “class libraries” or “class packages” that were offered by 
those languages and that were too distant from the real world and too fixed 
with the computers: one cannot forget that one of the principal advantages of 
the object-oriented programming was that the programmer was not forced to 
formulate what should happen in the computer and instead of it he was led to 
describe directly the thing to be modeled. 

During our studying of SIMULA (and during university lectures on it) we 
have been meeting the fact that class nesting can be iterated. For example, a 
main class can contain classes that are also main classes and contain other classes. 
Or a main class can contain a process with its own statements (we call them “life 
rules”), and among these statements there is a block containing formulations of 
classes, or even a block prefixed by a main class. 

Moreover, SIMULA introduced quasi-parallel systems that allowed switching 
the life rules of different objects. A new quasi-parallel system should rise when 
the computing process enters a block containing formulations of classes: the 
instances of these classes can enter the corresponding quasi-parallel system (as a 
more suitable, this rule replaced the original rule existing in the first definition of 
SIMULA, according to which a quasi-parallel system arose when the computing 
process entered a prefixed block) . As the blocks can be nested the quasi-parallel 
systems can be also nested, i.e. an element of a quasi-parallel system can enter a 
phase (a subblock of its life rules) deepened by its own quasi-parallel system. We 
slowly penetrated to the meaning of the nesting of classes and of quasi-parallel 
systems, and namely to their importance. 



3 Semantics of Nesting Main Classes and Quasi-Parallel 
Systems 

Later it appeared to us why the mentioned penetrating was so difficult. The 
reason rooted in the fact that one could not support his consideration by means 
of a result or an analogy discovered in another exact science like mathematics, 
logic or even physics or chemistry. If we view a main class as a computer image 
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of a formal theory (or a world viewing or a language), the nesting of the main 
classes has to be viewed as a formal theory the entities of that are able viewing 
to other (“their proper, private”) formal theories (and — analogously — as a 
world viewing which admits that the viewed components of the world have their 
own world viewings, or as a language that allows its words to manipulate with 
their own “internal” languages). 

Naturally, such attempt is not habitual and was not exactly studied by sci- 
ences. Nevertheless, in case of the interpretations by means of the formal theories 
and/or of the world viewings, certain analogies in the real world exist; we dis- 
covered some of them and then we included them into our work to implement 
computer models. This will be described in the next sections. The interpretation 
in case main class = language seems to fail any suitable application. 

A more difficult interpretation expected us in case of nested quasi-parallel 
systems but the first steps in mental governing the class nesting enabled to 
understand also the nesting of the quasi-parallel systems. 

4 First Steps in Nesting Modeling-Theory 

The basic scheme of main class nesting in SIMULA can be outlined by means of 
the following block: 

begin class mainl; 

begin class conceptl; ... ; 
class concept2; ... ; 

... etc. other declarations; 
class internal_modeller ; 
begin class main2; 

begin class conceptA; ... ; 

class concepts; ... ; 

... etc. other declarations; 
possibly: statements of main2 ... 
end of class main2; 
possibly: statements of 

internal_modeller ; 
end of internal_modeller ; 
possibly: statements of mainl; 
end of mainl; possibly: statements of the block 
end of the block; 

One can see that in the block a certain world viewing called mainl is in- 
troduced so that it contains some concepts called conceptl, concept2, . . ., 
which are “habitual and conventional” for that world viewing, and a concept 
called internaljnodeller that has his own world viewing called main2 and us- 
ing concepts called conceptA, concepts, . . . What happens in the “mind” of 
that modeler can be independent of what happens in the “world” composed of 
the instances of concepts belonging to mainl, but can interact with them. Note 
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that among the instances, those of the “habitual and conventional” concepts can 
occur and those of the internaljnodeller as well. Let us present an example. 

The block is a model of dining mathematicians, concept 1, concept2 etc. 
are dishes, plates, knives, forks, serving persons, tables, chairs etc., while the 
class internaljnodeller is a concept of dining mathematician who cannot eat 
without thinking on geometry; in case he is eating together with other similar 
mathematicians he wishes to discuss with them about the professional questions 
he is having in his mind. The classes conceptA, conceptB etc. occurring in class 
main2 are e.g. classes point, line, circle etc., occurring in class geometry 
mentioned in Section 2. 

In place of dining mathematicians we can consider dining staff officers who do 
not thing on a static world of geometry but who imagine the battle that expects 
them: each of them has his own vision, he controls it by the rules of causality, 
probability and time flow and exchanges information on the imaginary battle 
with his staff colleagues. Note that two sorts of time occur in such a metaphor: 
the time during that the officers are eating and discussing, and the imagined time 
of the future battle. That natural metaphor leads us to attempt to quasi-parallel 
system nesting and to nesting of simulation models. 

Although both the examples can seem rather strange, they led to modifica- 
tions that could be applied in practice, even in industrial domain. The dining 
mathematicians should be replaced by working persons, because the persons can 
mutually interact not only during eating but during working, too, and they can 
govern not only things serving for eating but also components of the production 
and/or logistic systems in which they are working. The session of dining officers 
can be replaced by that of discussing experts who should decide of a certain — 
hopefully optimal — variant of a system that they have to design. 

And — moreover — the thinking human can be replaced by a computer or 
by a human with his own computer that helps him to make decisions; namely 
a simulating computer can help a person to improve his imagining, which could 
be viewed as imperfect and poor “mental simulation” . Such a transformation 
appears to be useful in case one should automate a system and tries to transfer 
the humans mental processes to those of computing automatons. 

In the community of SIMULA users a habitude started in 1993: the object- 
oriented programming admitting the objects to have their “private” classes and 
thus enabling them to use these classes for to model “thinking”, imagining, 
simulation and in general modeling was called super- object- oriented programming 
[5], [6]. 

5 Further Steps in Nesting Modeling — Pseudosimulation 

The roots of the first real experiences with application of nesting modelling arose 
in use of a so called pseudosimulation or fictitious simulation [7]. The contents 
of those terms can be explained as follows: 

Simulation programming tools were designed to make easier the implementa- 
tion of simulation models: using these languages, a simulationist does not need 
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to describe what should happen in the computer (i.e. an algorithm) but what 
happens (or should happen) in the simulated system. The automatic scheduling 
of events (and — for some simulation languages — of processes) at a common 
simulation time axis is one of the most impressive helping aspects of the discrete 
event simulation languages. Besides describing real systems or systems that are 
considered as possible real things in a future, one can use the simulation lan- 
guages to describe systems that are evidently fictitious. Ole- Johan Dahl shown 
already in 1966 that such an affair can be used to make easier an implementation 
of certain algorithms [8] : instead to describe them in a traditional programming 
language one imagines a system that could produce the same data as the desired 
algorithm, and describes it in a simulation language. Dahl presented two exam- 
ples, namely Eratosthenes sieve to compute prime numbers, and determining 
the shortest path in a graph. The last example was implemented as a simulation 
model of the following fictitious system. 

Certain “pulses” leave the start node along all possible connections leading 
out from it. The rates of movement are the same. Any branching of the graph is 
in one of two following states: marked or free; at the beginning, every branching 
is free. When a pulse enters a free branching it marks it and then it multiplies 
(similarly as microorganisms and — in general — cells do) so that its “descen- 
dants” occupy all connections leading from the branching. When a pulse enters 
a marked branching it disappears. Each of the pulses carries information on its 
“ancestor” and on the connection along it moved. When a pulse enters the tar- 
get point, it and its “genealogy” determine the shortest path. It is evident that 
a good discrete event simulation language makes easy not only scheduling the 
pulses marking of nodes and their multiplying, but also enables to formulate only 
one class of pulses with its life rules for a general concept of pulse. Naturally, 
something like the multiplying pulses is a fictitious affair. 

The shortest path is often determined in the production and logistic systems, 
and nesting a subroutine for it is often necessary in simulation models of such 
systems. We mapped that subroutine to a simulation model of the system of 
pulses presented above. Its nesting in a simulation model of a real systems was 
described in SIMULA according to the following principles: 

real_system_model : SIMULATION 

begin class node; begin ref (head) environment ; ... ; 
class connection(start_node, end_node) ; ... ; 
process class f ixed_machine ; ... ; 
process class conveyor; 
begin ref (node)present_pIace ; 

procedure give_the_shortest_path_to (target) ; 
begin f ictitious_system_modeI : SIMULATION 
begin process class pulse 

(start_place , father, way); ... ; 
activate new pulse 
(present_place , none,...); 
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end of the fictitious system model; 
end of the shortest path routine; 

. . . life rules of conveyor (sometimes calling 
the procedure give_the_shortest_path_to) . . . 
end of class conveyor; 

... forming the structure of real system model, 
activating conveyors, etc. 

end of the real system model; 

In 1990, we started with using that principle in simulation of machinery 
production systems using induction carriages for its operation logistics [10], and 
then we proceed by a lot of other applications (see e.g. a detailed description of 
many SIMULA texts at pages 175-278 of [11]). 

In the SIMULA text there are two occurrences of SIMULATION applied as 
prefixes at different block levels. This phenomenon is not in a contradiction to 
SIMULA principle forbidding subclassing across block levels, because each of the 
occurrences is considered as an identifier completely different from the other one. 
According our experience, every SIMULA compiler for PC compatible machines 
behaves in that manner. 

6 Other Applications of Pseudosimulation 

A description of application of pseudosimulation using other fictitious models 
than that of the pulses and applied for other reasons that the shortest paths 
computing, can be seen in [7]. In a greater part, they applied pseudosimulation 
nesting in a simulation model. But the nesting can be realized inversely, namely 
so that a simulation was nested in a model of a fictitious system that governed 
a simulation study (a sequence of simulation experiments controlled to lead to 
some target). 

An excellent example was presented in [12] and [13]. It roots in the metaphor 
of the dining mathematicians presented in Section 4. Let us describe it. 

The fictitious system is a session of several experts (may be from 5 to 10), 
each of them having a computer. The task of the session is to get a proposal of 
a (sub)optimal variant of a certain dynamic system. 

At the beginning, each of the experts simulates the system from (simulated) 
time equal zero so that he respects his own opinion on the optimum variant. The 
experts simulate contemporarily and interrupt the simulation experiments when 
accessing a certain (simulated) time T. 

Then they observe the results — often time integrals of some variables (e.g. 
of queue lengths, waiting times, income or expenditure) — and exchange infor- 
mation about that. One of the experts — let us call him W — recognizes his 
variant having led to the worst results; inspired by the variants of his colleagues, 
he processes the parameters of their variants to form a new variant for himself. 

Then his colleagues continue their simulation experimenting from to T + D. 
SIMULA allows to model the experts so that they can simply proceed the simu- 
lation computing from (simulated) time T. Only W has to start the simulation 
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of his new variant from the beginning, i.e. from time equal to zero, but he leads 
the simulation until the same time as his colleagues do, i.e. to T + D. Then the 
information exchange among the experts, leading to a new refusing of a variant 
and replacing it by that with — hopefully — better behavior takes place. 

The experts simulate until time T +2D, and the cycle <simulation — commu- 
nication — formulation of a new variant > is repeated until a certain (simulated) 
time T + KD (where K uses to be from 100 to 500). In that state the experts 
come near to the optimum variant and in commercial applications the best vari- 
ant being handled by them is sufficient. The theory says that such a way to 
the optimum realized during the simulation experimenting should take 50% of 
the computing time necessary for the conventional optimizing, which tests any 
variant by a simulation from zero until T -|- KD. Nevertheless commercial appli- 
cations in steel metallurgy, machine production, neurophysiology, services and 
other branches demonstrated that the described method needs less computing 
time than about 15 percent of the time necessary for the conventional optimizing. 

A natural question exists whether it would be necessary to apply conventional 
optimizing with simulation up to T -|- ATI?. There is a simple positive answer to 
such a question, which is supported by the following fact. 

Simulation is applied for getting information on complex systems. For such 
systems it is difficult to determine the duration of the initial transitive phase 
during which the behavior of the system is exceptional and cannot be used for 
any decision concerning the optimum; the optimum design of a system should 
be designed according to its behavior in its steady state, which takes place after 
the initial phase. The information on the important behavior of the system (and 
therefore its optimizing, too) should be based at simulation experiments that 
map the system behavior during a certain duration T$ of its steady state. Nev- 
ertheless — because of the complexity of the simulated system — the duration 
of the initial phase is not known and one can formulate an extreme optimistic 
hypothesis Tqpt or an extreme pessimistic hypothesis Tpps about it, accepting 
that the true value Tx is somewhere between them. But it is just the method 
described above that enables to use the true duration for the optimizing: T is 
taken as Tqpt + Ts and T -|- KD as Tpps + Ts, which imply D = '^pes-^opt ^ 



7 Reflective Simulation 

When a system S is to be designed simulation is often used to give data that 
tell the designers about the behavior of various variants that they think on. 
Simulation models for that purpose can be called external. S can use simulation 
when it will operate: such a simulation can for instance test possible consequences 
of the decisions made during the operating of S. Let the simulation models used 
during the real existence of S and existing as its components be called internal 
ones. It is evident that both the internal models and the external ones concern 
the same thing and that it would be dummy to describe the external model in 
a language different from that applied for describing the internal ones. 
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The simulationists often say with humor that simulation is the worst way to 
get data about a system and that it should be replaced by a better way in case 
such a way exists (e.g. an analytical method, a direct experiment, a heuristic 
technique, or a search in a data base). They can say it, because they know 
that in case of complex systems there is no way to get data on them, excepting 
simulation. When the designers think about a system to contain a simulating 
computer, they have to accept that simulation is quite necessary, otherwise they 
would demonstrate their low professional level. 

The consequence is that the external model should reflect not only “hard 
elements” of the designed system (machines, buildings, storages, . . . ) but also 
“soft elements” , namely computers that exist contemporaneously with the hard 
elements and that sometimes simulate. To neglect the simulating computers 
in the external model would be a demonstration of one of two errors of the 
designers: if in such a state the external model gives good information the internal 
models can be rejected from the real system, too, and — oppositely — if the 
internal models are necessary to serve to the operation of the designed system, 
the external model without them would give false data about the studied system. 

Therefore the external model of S has to contain the images of its simulating 
soft elements, i.e. the internal models should be nested in the external model. The 
phenomenon that it is not practiced roots in the fact that with use of common 
simulation tools (simulation languages, packages and object-oriented program- 
ming systems) it is too difficult to implement such an external model. Never- 
theless SIMULA allows it; in principle the internal models can be nested in the 
external model similarly as outlined at the end of Section 5: real_system_model 
corresponds to the external model while f ictitious_system_model represents 
the internal one. 

There is a special property in the case presented in this Section: as it was 
mentioned, both the models concern the same thing and therefore what is for- 
mulated in real_system_model should be almost the same as what is declared 
in f ictitious_system_model, which — of course — cease being a model of a 
fictitious system. In such a case we speak on reflective simulation, because the 
internal model should reflect what exists (or may exist) in the external one. 

The practice of the reflective simulation carries some obstacles that were 
already overcome (see e.g. exhausting recommendations in manuals [14] and 
[15]). But there is a special aspect of the reflective simulation that has to be 
analyzed in some details. In concerns a programming error that can come just 
in case of reflective simulation and that is called transplantation. Let us describe 
that error and its possible consequences. 

We already wrote that in case of the reflective simulation the language used 
for the description of the internal model should be almost the same as that used 
for the description of the external model. Suppose Q to be a name of a storage 
and R a name of an element that can enter Q. What can happen in the external 
model must be admitted for being mapped in the internal one and therefore the 
fact that R enters Q can occur in both the models. But what happens when one 
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makes an error and writes in his model that R of the internal model enters Q of 
the external one? 

Such an event has no analogy in the real world, because it means that some- 
thing represented by means of electronic phenomena inside a computer existing 
in the real world enters into a storage that exists in the same real way as the 
computer. Nevertheless, one could say transplantation to be a certain analogy 
of the non-Euclidean geometries, about which 200 years ago one thought to be 
without sense and then their meaning and even their importance was discov- 
ered: although they seemed dummy they contain no internal contradiction. But 
it cannot be said about the transplantation [16]. If R enters Q it is handled 
as a component of the external model. It can have a neighbor P in Q, which 
belongs to the external model similarly as Q. But R can have a relation to 
another element M, which was introduced in an ordinary way before the trans- 
plantation; therefore M should belong to the internal model. Then, through the 
way M-i?-neighbor of R, the computing process can handle P as if it would 
be an element of the internal model. An equivalent event can be accessed by 
the way M--i?~storage of R: Q will be handled as a component of the internal 
model. Similar steps can be repeated, until both the external and internal models 
are hopelessly intermixed, and then the computing process fail into a collapse, 
emitting a message like “non-existing address” . A reverse reconstruction of the 
steps from the message to the first erroneous step is impossible and therefore 
the place of the real programmer’s error cannot be determined and repaired. 
Detailed experimenting leading to the collapses were presented in [16]. 

The ways of making the users safe against transplantation can be built in 
the run time phase or in the compiling one. The run time phase ways against 
transplantation do not limit the user’s freedom but lead to an enormous prolon- 
gation of the run: every assignment must be tested whether it does not perform 
a transplantation. The security built in a compiler does not enlarge the run of 
the compiled program but implies restrictions of the language. Especially in case 
of SIMULA, we thought during 25 years it being secure against transplantation 
so strongly that it did not allow any communication between the external and 
internal models. Not sooner than in 1993 (therefore 26 years after the first pro- 
posal of the SIMULA principles and 25 years after the exact definition of its 
syntax and semantics) we discovered how to overcome the limitations (it is a 
splendid property of SIMULA that the tricky ways of the overcoming did not 
lead to any violation of its security!). 

The SIMULA security roots in two syntactical restrictions: one of them as- 
serts that a quasi-parallel system exists only contemporary with a subblock, 
while the second one states that the subblocks cannot get names (identifiers). 
As the simulation needs quasi-parallel systems, the internal and external mod- 
els must be programmed as subblocks, but the consequence is that neither the 
external model nor the internal one cannot get names. Therefore one cannot 
express whether a name of an element (e.g. M , P, Q and R used in the example 
presented above) concerns the internal model or the external one, and the only 
“common rule of nesting blocks” is applicable: inside the block corresponding to 
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the internal model such names point to its elements while the elements of the 
external model having the same names are not accessible there, and outside this 
block the names point to the elements of the external model while those of the 
internal one are inaccessible. 

After the mentioned long period of 25 years, we discovered a trick, that will 
be demonstrated at the example of the name Q. Let us start from the exam- 
ple presented at the end of Section 5, and modify it slightly: let us introduce 
externaljnodel in place of real_system_model and internaljnodel in place 
of f ictitious_system_model, let us change the classes reflecting the simulated 
object (we are no oriented to the conveyor and its shortest path treatments 
more), and let us make a rather poetical (or dadaistic?) step by using name 
world for the class of computers that use the internal models. Let us introduce 
class helpingjtorce and a name assistant for one of its instances; it reflects 
no real entity of the simulated system but will help to overcome the barriers 
given by SIMULA: when the assistant is demanded to give Q_ it turns to what 
is called Q and presents it as Q_. As the assistant exists in the external model 
and out of the internal model, it handles Q belonging to the external model. 

Now let us turn to class world. It contains a subblock internal-model. Outside 
this block, world contains function called Q, which is defined so that it delegates 
the assistant to give its Q_; the assistant gives Q of the external model and 
therefore — according to the rules of SIMULA — when this world. Q is met inside 
world, it points to Q of the external model. It holds also inside the internal model 
but if in that model an isolated text Q is met, the SIMULA rules determine that 
it is Q of the internal model. Therefore in the internal model one can distinguish 
between the both storages by using Q and this world. Q: Q points to Q of the 
internal model while this world. Q points to Q of the external one. Thus — for 
example — Q . capacity : =this world . Q . capacity expresses copying the value 
of attribute capacity of the storage Q existing in the external model, as the 
value of attribute capacity of the image of Q in the internal model. In SIMULA, 
this world. Q is to be read as “Q of this world”, which illustrates the reason of 
the strange name given to the computer. 

external_model : SIMULATION 

begin class storage; ... ; 
ref (storage) Q ; 

process class conveyor; ... ; 
class helping-! orce ; 

begin ref (storage)procedure Q_; Q_:-Q; 

end of class helping-! orce ; 
ref (helping-force) assistant ; 
process class world; 

begin ref (storage)procedure Q; Q : -assistant . Q- ; 
procedure simulate( . . . ) ; 
begin internal-model: SIMULATION 
begin class storage; ... ; 
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ref (storage) Q ; 

end of the internal model; 
end of procedure simulate; 

. . . life rules of class world . . . 
end of class world; 
assistant : -new helping_f orce ; 

. . . forming the structure of real system model . . . , 
activating its components ... ; 
activate new world; 

end of the external model; 

At the present time, a software system is implemented to translate a con- 
ventional simulation model written in SIMULA into an (external) model with 
computers that are able to observe the state of the system in that they occur, to 
generate a simulation model according it and to use it as internal model [17], [18]. 
Naturally, both the purpose of the internal model and the moments when it is to 
be applied depend on the users wishes and cannot be automatically generated. 
The software was made under the Barrande programme (bilateral cooperation 
between French and Czech universities, namely between the University of Os- 
trava and Blaise Pascal University in Clermont-Ferrand) and also supported by 
the institutional research scheme of the University of Ostrava. 

8 An Example 

During 1995-2000 the author of this paper was a member of an international 
consortium working under support of the European Commission at two Coperni- 
cus projects oriented to modernization of sea harbors by means of using modern 
information technologies [11], [19], [20]. Among the necessary tasks of the consor- 
tium work, an implementation of programming tools for simulation of container 
yards appeared. The tools had to be as general as possible, reflecting the wide 
spectrum of the container yards over the world. 

The author of this paper oriented his work to that subject and used SIMULA 
to implement the mentioned tools: the subclassing, enabled by this language, ap- 
peared very suitable to realize the task (note that it was not only the subclassing 
of elementary classes like those of containers, transport tools etc. but also sub- 
classing of main classes, i.e. in case of different “world viewings” to the container 
yards). 

Using SIMULA there were no essential problems [21]. For computing the 
path of the ground-moving transport tools (further: GMTT, e.g. forklifts), the 
pseudosimulation of distributed pulses was applied similarly as it was presented 
in Section 5. Therefore the elaborated simulation models of the container yards 
contained nested simulation models of fictitious systems [22] . 

When a transport tool gets an instruction to move to a certain place a path 
is computed for its moving. In case of a GMTT the path must be composed of 
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free places of the labyrinth among the stored containers, i.e. of places at which 
there is no container and no GMTT. The path is computed immediately when 
the instruction for moving is emitted and the computation is based on using 
the places that are free at the moment of the computing (the duration of the 
computing is neglected). But the computed path is then used during a certain 
non-zero time and during it the configuration of the free places can change: 
moving along the computed path, the GMTT can face to a barrier formed by a 
(temporarily) stored container or by another GMTT. Note that such barriers can 
arise only in case that more than one GMTT can contemporaneously operate in 
a container yard, but so it is just in many real situations. 

A lot of control algorithms were proposed for what a GMTT should do when 
meeting a barrier. Hundreds of simulation experiments shown that any proposed 
algorithm led the system to deadlocks that stepwise cumulated in time until a 
complete collapse of moving in the whole yard. The solution was found in testing 
the computed path by simulation, in the following way. 

Suppose at time t a GMTT F gets an instruction to move. We will say F 
to be semiactive. There may be other GMTTs that are already moving; their 
ways were already computed, tested and fixed at a time less than t and cannot 
be changed. Let us call them active GMTT. The other GMTT — in case they 
exist — are not moving, i.e. they have no path and a path can be assigned 
them later, at a time greater than t. A path P is computed for F and then a 
certain future of the container yard is simulated, supposing that P is accepted. 
The simulation experiment reflects also all moves of the active GMTT and is 
concluded by one of the following two events: the happy end is the event when 
F accesses the end of P, and the bad end is a conflict between F and a barrier. 
In case of the happy end the path P is accepted and F moves along it. In case 
of the bad end the place of the barrier is marked by a fictitious container and 
the process is repeated: a new path is computed for F and tested by simulation; 
because of the fictitious container, it will differ from P. So the process of two 
nested simulations — that of system of fictitious pulses and that of the future 
of the container yard — is repeated until a safe path is got. Many simulation 
experiments shown that in a realistic situation a safe path is always accessed [23] , 
[24]; only in case the external simulation experiment is started so that more (e.g. 
four) GMTTs are cumulated around the first manipulated container, a deadlock 
comes immediately at the start, but no practiced worker of a container yard 
begins with such a bizarre decision step. 



9 New Horizons 

As we already mentioned, the simulation models of container yards, organized 
according to the described structure are external models containing two different 
internal ones so that one of them causes their use to be reflective simulation. 
Nowadays, the classification of the simulation models to those of real systems 
and those of fictitious systems seems to be clear and useful, and therefore a 
classification of the nested models seems to be almost clear; we wrote “almost”. 
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because beside the reflective simulation and the simulation using nested pseu- 
dosimulation, the third sort can be taken into account, characterized so that in 
a model of a real system S there is another model nested, simulating a system 
that is real but very different from S. Although the idea is natural and SIMULA 
allows applying it, its real application does not exist (it offers to be applied in 
concurrent engineering [25]). 

But SIMULA opens other horizons, the substance of which is in mixing prop- 
erties of real and fictitious systems. Although it may seem crazy, such systems 
can be simulated, their models can be nested into those of “uncrazy” systems and 
may be applied. An impressive example presented Novak (a student of Charles 
University in Prague) in his master thesis (the substance was published in En- 
glish in [26]). 

Computing a path of a GMTT, we try to get it as short as possible. The 
consequence of this intention is, that we automatically exclude the variants in 
which the GMTT should wait or even return. In Section 5 it was shown that the 
fictitious system of pulses produces only paths without waiting and without re- 
turn, because when a pulse returns to a marked place it disappears. Nevertheless 
the idea to exclude the waiting and returns is not good in case the configuration 
of free places can change. In general, a GMTT can move near to a barrier, then 
it can wait there some time and then it can continue to move when the barrier 
disappears, and the time necessary for accessing the target can be smaller than 
that necessary for a moving along a rather long path without waiting. Moreover, 
even the following situation can exist without implying a deadlock: 

There is a narrow way W between two walls formed by stored containers; the 
end places of W are Y and Z. Between them, but near to Y, there is a place A 
at W and beside it there is a place C in one of the walls, where occasionally 
no container is placed; C forms a certain alcove of W. At a place B between A 
and Z, there is a GMTT called G moving to the end Y, while near Y there 
is another GMTT called F. Its task is to move behind place Z. If the return 
and waiting is not accepted F should use another path than that through W; 
such a deviation could take much time. If a possibility to return and to wait 
exists F can move to A and then to C, there it can wait until G moves to a place 
between A and Y. Then F can return from G to A and to continue to Z. 

Novak included an ability to generate such decisions so that he united both 
the internal models into a certain mix in which the images of real (active) 
GMTTs and fictitious pulses exist in a common simulated time and mutually 
interact: when the shortest path for a GMTT has to be determined the fictitious 
pulses are interpreted as all logically possible future moves of the semiactive 
GMTT and the moves are faced to meet with those moves and barriers that 
were already determined before and are caused by the active GMTT. If a pulse 
meets a barrier it does not disappear but it waits and when an image of an active 
GMTT moves along marked places it liquidates their marks so that the waiting 
pulses can continue to move through them. 
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10 Conclusion 

Computer models penetrate more and more into the world in that we exist. 
The models reflect components of this world and — if using the terms hard and 
soft, introduced in Section 7 — we can classify the models into two different 
groups: the models of the hard components (production/logistic systems, living 
organisms, their organs and their communities, physical systems, buildings and 
their complexes etc.) and those of the soft components (e.g. data bases, com- 
puter networks and operation systems). The number of the models of the hard 
components is much grater because our world was originally composed of such 
components. Contemporarily with the computerization and informatization of 
the human society, the models will have to reflect penetrating of the computer 
models into the systems composed of hard components, i.e. have to map that 
the hard components are more and more bound by the soft ones, or — more 
precisely — by the models the soft components carry. The nesting of models will 
reflect the fact that the modeled hard components of the world develop to be 
less and less autonomous, influenced by soft ones. 

This historical process leads to a certain task, namely to the necessity of 
studying the models of systems using models or — equivalently — to study 
theories concerning entities that carry theories. But — as we already wrote in 
Section 3 — the sciences give no support for it (the genial contribution given 
to mathematical logic and to our civilization by Kurt Gdel is too elementary 
than to be used as an effective aid). SIMULA surprises not only because it is a 
very effective stimulus for the mentioned task but also because of applications 
it offers. Already 35 years ago, the authors of SIMULA contributed not only by 
their ideas but also by their hard work that led the ideas until implementation 
functioning independently of the human thinking. 
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Abstract. We study an interesting family of cooperating coroutines, 
which is able to generate all patterns of bits that satisfy certain fairly 
general ordering constraints, changing only one bit at a time. (More pre- 
cisely, the directed graph of constraints is required to be cycle-free when 
it is regarded as an undirected graph.) If the coroutines are implemented 
carefully, they yield an algorithm that needs only a bounded amount of 
computation per bit change, thereby solving an open problem in the field 
of combinatorial pattern generation. 



Much has been written about the transformation of procedures from recursive to 
iterative form, but little is known about the more general problem of transform- 
ing coroutines into equivalent programs that avoid unnecessary overhead. The 
present paper attempts to take a step in that direction by focusing on a reason- 
ably simple yet nontrivial family of cooperating coroutines for which significant 
improvements in efficiency are possible when appropriate transformations are 
applied. The authors hope that this example will inspire other researchers to 
develop and explore the potentially rich field of coroutine transformation. 

Coroutines, originally introduced by M. E. Conway [2], are analogous to 
subroutines, but they are symmetrical with respect to caller and callee: When 
coroutine A invokes coroutine B, the action of A is temporarily suspended and 
the action of B resumes where B had most recently left off. Coroutines arise 
naturally in producer/consumer situations or multipass processes, analogous to 
the “pipes” of UNIX, when each coroutine transforms an input stream to an 
output stream; a sequence of such processes can be controlled in such a way that 
their intermediate data files need not be written in memory. (See, for example. 
Section 1.4.2 of [9].) 

The programming language SIMULA 67 [3] introduced support for co- 
routines in terms of fundamental operations named call, detach, and resume. 
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Arne Wang and Ole-Johan Dahl subsequently discovered [20] that an extremely 
simple computational model is able to accommodate these primitive operations. 
Dahl published several examples to demonstrate their usefulness in his chapter 
of the book Structured Programming [4]; then M. Clint [1] and O.-J. Dahl [6] 
began to develop theoretical tools for formal proofs of coroutine correctness. 

Another significant early work appeared in R. W. Floyd’s general top-down 
parsing algorithm for context-free languages [8], an algorithm that involved 
“imaginary men who are assumed to automatically appear when hired, disap- 
pear when fired, remember the names of their subordinates and superiors, and 
so on.” Floyd’s imaginary men were essentially carrying out coroutines, but 
their actions could not be described naturally in any programming languages 
that were available to Floyd when he wrote about the subject in 1964, so he 
presented the algorithm as a flow chart. Ole-Johan Dahl later gave an elegant 
implementation of Floyd’s algorithm using the features of SIMULA 67, in §2.1.2 
of [5]. 

The coroutine concept was refined further during the 1970s; see, for example, 
[19] and the references cited therein. But today’s programming languages have 
replaced those ideas with more modern notions such as “threads” and “closures,” 
which (while admirable in themselves) support coroutines only in a rather awk- 
ward and cumbersome manner. The simple principles of old-style coroutines, 
which Dahl called quasi-parallel processes, deserve to be resurrected again and 
given better treatment by the programming languages of tomorrow. 

In this paper we will study examples for which a well-designed compiler could 
transform certain families of coroutines into optimized code, just as compilers 
can often transform recursive procedures into iterative routines that require less 
space and/or time. 

The ideas presented below were motivated by applications to the exhaus- 
tive generation of combinatorial objects. For example, consider a coroutine that 
wants to look at all permutations of n elements; it can call repeatedly on a 
permutation-generation coroutine to produce the successive arrangements. The 
latter coroutine repeatedly forms a new permutation and calls on the former 
coroutine to inspect the result. The permutation coroutine has its own internal 
state — its own local variables and its current location in an ongoing computa- 
tional process — so it does not consider itself to be a “subroutine” of the inspec- 
tion coroutine. The permutation coroutine might also invoke other coroutines, 
which in turn are computational objects with their own internal states. 

We shall consider the problem of generating all n-tuples ai02 . . . a„ of Os 
and Is with the property that Uj < Uk whenever j k is an arc in a given 
directed graph. Thus aj = 1 implies that Uk must also be 1; if Uk = 0, so is aj. 
These n-tuples are supposed to form a “Gray path,” in the sense that only one 
bit Uj should change at each step. For example, if n = 3 and if we require 
oi < 03 and 02 < 03, five binary strings 030203 satisfy the inequalities, and one 
such Gray path is 



000, 001, Oil, 111, 101. 
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The general problem just stated does not always have a solution. For exam- 
ple, suppose the given digraph is 



so that the inequalities are oi < 02 and 02 < oi; then we are asking for a way 
to generate the tuples 00 and 11 by changing only one bit at a time, and this is 
clearly impossible. Even if we stipulate that the digraph of inequalities should 
contain no directed cycles, we might encounter an example like 




in which the Gray constraint cannot be achieved; here the corresponding 4-tuples 

0000 , 0001 , 0011 , 0101 , 0111,1111 

include four of even weight and two of odd weight, but a Gray path must al- 
ternate between even and odd. Reasonably efficient methods for solving the 
problem without Grayness are known [17, 18], but we want to insist on single- 
bit changes. 

We will prove constructively that Gray paths always do exist if we restrict 
consideration to directed graphs that are totally acyclic, in the sense that they 
contain no cycles even if the directions of the arcs are ignored. Every component 
of such a graph is a free tree in which a direction has been assigned to each 
branch between two vertices. Such digraphs are called spiders, because of their 
resemblance to arachnids: 




(In this diagram, as in others below, we assume that all arcs are directed up- 
wards. More complicated graph-theoretical spiders have legs that change direc- 
tions many more times than real spider legs do.) The general problem of finding 
all oi . . . a„ such that aj < when j ^ fc in such a digraph is formally called 
the task of “generating the order ideals of an acyclic poset”; it also is called, 
informally, “spider squishing.” 
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Sections 1-3 of this paper discuss simple examples of the problem in prepara- 
tion for Section 4, which presents a constructive proof that suitable Gray paths 
always exist. The proof of Section 4 is implemented with coroutines in Section 5, 
and Section 6 discusses the nontrivial task of getting all the coroutines properly 
launched. 

Section 7 describes a simple technique that is often able to improve the 
running time. A generalization of that technique leads in Section 8 to an efficient 
coroutine-free implementation. Additional optimizations, which can be used to 
construct an algorithm for the spider-squishing problem that is actually loopless, 
are discussed in Section 9. (A loopless algorithm needs only constant time to 
change each n-tuple to its successor.) 

Section 10 concludes the paper and mentions several open problems con- 
nected to related work. 

1 The Unrestricted Case 

Let’s begin by imagining an array of friendly trolls called T\, T 2 , . . . , T„. Each 
troll carries a lamp that is either off or on; he also can be either awake or asleep. 
Initially all the trolls are awake, and all their lamps are off. 

Changes occur to the system when a troll is “poked,” according to the fol- 
lowing simple rules: If is poked when he is awake, he changes the state of his 
lamp from off to on or vice versa; then he becomes tired and goes to sleep. Later, 
when the sleeping Tk is poked again, he wakes up and pokes his left neighbor 
Tk-i, without making any change to his own lamp. (The leftmost troll Ti has 
no left neighbor, so he simply awakens when poked.) 

At periodic intervals an external driving force D pokes the rightmost troll T„, 
initiating a chain of events that culminates in one lamp changing its state. The 
process begins as follows, if we use the digits 0 and 1 to represent lamps that 
are respectively off or on, and if we underline the digit of a sleeping troll: 

. . . 0000 Initial state 
. . . 0001 D pokes T„ 

. . . 0011 D pokes T„, who wakes up and pokes T„_i 
. . . OOIQ D pokes T„ 

. . . 0110 D pokes T„, who pokes T„_i, who pokes T „_2 
. . . 0111 D pokes T„ 

. . . OlQl D pokes T„, who pokes T„_i 

The sequence of underlined versus not-underlined digits acts essentially as a 
binary counter. And the sequence of digit patterns, in which exactly one bit 
changes at each step, is a Gray binary counter, which follows the well-known 
Gray binary code; it also corresponds to the process of replacing rings in the 
classic Ghinese ring puzzle [12]. Therefore the array of trolls solves our problem 
of generating all n-tuples 0102 . . . a„, in the special case when the spider digraph 
has no arcs. (This troll-oriented way to generate Gray binary code was presented 
by the first author in a lecture at the University of Oslo in October, 1972 [10].) 
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During the first 2” steps of the process just described, troll T„ is poked 2” 
times, troll T„_i is poked 2”“^ times, . . . , and troll T\ is poked twice. The last 
step is special because Ti has no left neighbor; when he is poked the second 
time, all the trolls wake up, but no lamps change. The driver D would like to 
know about this exceptional case, so we will assume that T„ sends a message 
to D after being poked, saying ‘trwe’ if one of the lamps has changed, otherwise 
saying ^ false’. Similarly, if 1 < A: < n, will send a message to Tk+i after being 
poked, saying Hrue’ if and only if one of the first k lamps has just changed state. 

These hypothetical trolls Ti, ..., T„ correspond to n almost-identical co- 
routines poke[l], ..., poke[n], whose actions can be expressed in an ad hoc 
Algol-like language as follows: 

Boolean coroutine poke[k]; 
while true do begin 

awake: a[k] := 1 — a[k]\ 
return true ; 

asleep: if fc > 1 then 

return poke [k — 1] 
else 

return false ; 

end. 

Coroutine poke [k] describes the action of T^, implicitly retaining its own state of 
wakefulness: When poke [fc] is next activated after having executed the statement 
‘return true’ it will resume its program at label ‘asleep’; and it will resume at 
label ‘awake’ when it is next activated after ‘return poke[k — 1]’ or ‘return 
false’. 

In this example and in all the coroutine programs below, the enclosing ‘while 
true do begin (P) end’ merely says that program (P) should be repeated end- 
lessly; all coroutines that we shall encounter in this paper are immortal. (This 
is fortunate, because Dahl [6] has observed that proofs of correctness tend to be 
much simpler in such cases.) 

Our coroutines will also always be “ultra-lightweight” processes, in the sense 
that they need no internal stack. They need only remember their current posi- 
tions within their respective programs, along with a few local variables in some 
cases, together with the global “lamp” variables a[l], . . . , a[n]. We can imple- 
ment them using a single stack, essentially as if we were implementing recursive 
procedures in the normal way, pushing the address of a return point within A 
onto the stack when coroutine A invokes coroutine B, and resuming A after B 
executes a return. (Wang and Dahl [20] used the term “semicoroutine” for this 
special case. We are, however, using return statements to return a value, in- 
stead of using global variables for communication and saying ‘detach’ as Wang 
and Dahl did.) The only difference between our coroutine conventions and ordi- 
nary subroutine actions is that a newly invoked coroutine always begins at the 
point following its most recent return, regardless of who had previously invoked 
it. No coroutine will appear on the execution stack more than once at any time. 
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Thus, for example, the coroutines poke [1] and poke [2] behave as follows when 
n = 2: 

00 Initial state 

01 poke [2] = true 

11 poke\2] = poke[l] = true 

IQ poke [2] = true 

10 poke [2] = poke [1] = false 

11 poke [2] = true 

Q1 poke[2] = poke[l] = true 

QO poke [2] = true 

00 poke [2] = poke [1] = false 

The same cycle will repeat indefinitely, because everything has returned to its 
initial state. 

Notice that the repeating cycle in this example consists of two distinct parts. 
The first half cycle, before false is returned, generates all two-bit patterns in 
Gray binary order (00, 01, 11, 10); the other half generates those patterns again, 
but in the reverse order (10,11,01,00). Such behavior will be characteristic of 
all the coroutines that we shall consider for the spider-squishing problem: Their 
task will be to run through all n-tuples oi . . . a„ such that aj < Uk for certain 
given pairs (j, k), always returning true until all permissible patterns have been 
generated; then they are supposed to run through those n-tuples again in reverse 
order, and to repeat the process ad infinitum. 

Under these conventions, a driver program of the following form will cycle 
through the answers, printing a line of dashes between each complete listing: 

( Create all the coroutines ); 

(Put each lamp and each coroutine into the proper initial state); 

while true do begin 

for k := 1 step 1 until n do write{a[k\); 

write {newline) ; 

if not root then write {" ", newline)-, 

end. 

Here root denotes a coroutine that can potentially activate all the others; for 
example, root is poke [n] in the particular case that we’ve been considering. In 
practice, of course, the driver would normally carry out some interesting process 
on the bits oi . . . a„, instead of merely outputting them to a file. 

The fact that coroutines poke [1], . . . , poke [n] do indeed generate Gray binary 
code is easy to verify by induction on n. The case n = 1 is trivial, because the 
outputs will clearly be 

0 

1 



1 

0 
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and so on. On the other hand if n > 1, assume that the successive contents of 
oi . . . a„-i are a^, a\, a 2 , ■ ■ ■ when we repeatedly invoke poke[n — 1], assuming 
that oq = 0 • • • 0 and that all coroutines are initially at the label ‘awake’; assume 
further that false is returned just before am when m is a multiple of 2"“^, 
otherwise the returned value is true . Then repeated invocations of poke [n] will 
lead to the successive lamp patterns 

crpO, CTol, Oil, oiO, 02 O, 02 I, 

and false will be returned after every sequence of 2" outputs. These are precisely 
the patterns of n-bit Gray binary code, alternately in forward order and reverse 
order. 

2 Chains 

Now let’s go to the opposite extreme and suppose that the digraph of constraints 
is an oriented path or chain, 

1^2^ ,n. 

In other words, we want now to generate all n-tuples 0102 . . . a„ such that 

0 < ai < 02 < • • • < a„ < 1, 

proceeding alternately forward and backward in Gray order. Of course this 
problem is trivial, but we want to do it with coroutines so that we’ll be able to 
tackle more difficult problems later. 

Here are some coroutines that do the new job, if the driver program initiates 
action by invoking the root coroutine hump [1] : 

Boolean coroutine bump[k]; 
while true do begin 

awakeO: ±f k < n then while bump[k+l] do return true; 



a[k] := 1; return true; 

asleepl : return false ; comment Ok ■ ■ ■ a„ = 1 . . . 1 ; 
awakel: a[A:] := 0; return true; 

asleepO: ±f k < n then while bump[k+l] do return true; 
return false ; comment Ok ■ ■ ■ a„ = 0 . . . 0 ; 

end. 

For example, the process plays out as follows when n = 3: 

000 Initial state 123 

001 bump[l] = bump[2] = bump[3] = true 123 

Oil bump[l] = bump[2] = true, bump[3] = false 12 

111 bump[l] = true, bump[2] = false 1 

111 bump [1] = false 1 

Qll bump[l] = true 12 

QQl &Mmp[l] = bump[2] = true 123 

QQQ bump[l] = bump[2] = bump[3] = true 123 

000 bump[l] = bump[2] = bump[3] = false 123 
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Each troll’s action now depends on whether his lamp is lit as well as on his state 
of wakefulness. A troll with an unlighted lamp always passes each bump to the 
right, without taking any notice unless a false reply comes back. In the latter 
case, he acts as if his lamp had been lit — namely, he either returns false (if just 
awakened), or he changes the lamp, returns true, and nods off. The Boolean 
value returned in each case is true if and only if a lamp has changed its state 
during the current invocation of bump [k] . 

{Note: The numbers ‘123’, ‘123’, ... at the right of this example correspond 
to an encoding that will be explained in Section 8 below. A similar column of 
somewhat inscrutable figures will be given with other examples we will see later, 
so that the principles of Section 8 will be easier to understand when we reach 
that part of the story. There is no need to decipher such notations until then; 
all will be revealed eventually.) 

The dual situation, in which all inequalities are reversed so that we generate 
all ai 02 . . . a„ with 

1 > Ol > 02 > • • • > On > 0, 

can be implemented by interchanging the roles of 0 and 1 and starting the 
previous sequence in the midpoint of its period: 

Boolean coroutine cohump[k]', 
while true do begin 

awakeO: a[k]:=l; return true; 
asleepl: ±f k < n then 

while cobump[k + l] do return true; 
return false ; comment ak ■ ■ ■ a„ = 1 . . . 1 ; 
awakel: if fc < n then 

while cobump[k + l] do return true; 
a[k] := 0 ; return true ; 

asleepO : return false ; comment ak ■ ■ ■ a„ = 0 . . . 0 ; 
end. 

A mixed situation in which the constraints are 

0 < ttn < ttn-l < • ■ • < ttm+l < < «2 < ' ' ' < Om < 1 

is also worthy of note. Again the underlying digraph is a chain, and the driver 
repeatedly bumps troll Ti; but when 1 < m < n, the coroutines are a mixture 
of those we’ve just seen: 

Boolean coroutine mbump[k]; 
while true do begin 

awakeO : if k < m then 

while mbump[k + l] do return true; 
a[k] := 1; return true; 
asleepl: ±fm<k A k<n then 

while mbump[k + l] do return true; 
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if k = 1 A m < n then 

while mbump[m+l] do return true; 
return false ; 

awake 1 : ±fm<k A k<n then 

while mbump[k + l] do return true; 
if k = 1 A m < n then 

while mbump[m + 1] do return true; 
a[k] := 0 ; return true ; 
asleepO: ±f k < m then 

while mbump[k + l] do return true; 
return false ; 

end. 

The reader is encouraged to simulate the mbump coroutines by hand when, say, 
m = 2 and n = 4, in order to develop a better intuition about coroutine behavior. 
Notice that when m « ^n, signals need to propagate only about half as far as 
they do when m = 1 or m = n. 

Still another simple but significant variant arises when several separate chains 
are present. The digraph might, for example, be 




in which case we want all 6-tuples of bits ai . . .uq with oi < 02 and 04 < 05 < og. 
In general, suppose there is a set of endpoints E = {ei, . . . , Cm} such that 

1 — Cl A * * * ^ OfYi "A 

and we want 

Ofc G {0, 1} for 1 <k <n; Ofc-i < Ofc for k ^ E. 

(The set if is {1, 3, 4} in the example shown.) The following coroutines ebump [k], 
for 1 < fc < n, generate all such n-tuples if the driver invokes ebump [em]' 

Boolean coroutine ebump[k]; 
while true do begin 

awakeO: if fc-|-l ^ifU{n-|-l} then while ebump[k+l] do return true; 
a[k] := 1; return true ; 

asleepl: if /cGif\{l} then return ebump[k'] 
else return false ; 
awakel: a[fc] := 0; return true; 

asleepO: if fc-|-l^ifU{n-|-l} then while ebump[k+l] do return true; 
if fcGif\{l} then return ebump[k'] 
else return false ; 



end. 
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Here k' stands for e^-i when k = ej and j > 1. These routines reduce to poke 
when E = {1, 2, . . . , n} and to hump when i? = {1}. If if = {1, 3, 4}, they will 
generate all 24 bit patterns such that oi < 02 and 04 < 05 < gq in the order 

000000, 000001, 000011, 000111, 001111, OOlQll, OOIQQI, OOIQQQ, 

011000, 011001, 011011, OlUll, OlQlll, OlQQll, OlQQQl, OIQQQQ, 

110000, 110001, noon, iioni, uiiii, uiQii, uiqqi, uiqqq; 

then the sequence will reverse itself: 

111000, 111001, llion, mill, llQlll, llQQll, iioooi, iioqqq, 

QIOOOO, QlOOOl, QlOOll, QlOlll, QUlll, QUQll, QUQQl, QUQQQ, 

QQIOOO, QQlOOl, QQlOll, QQUll, QQQlll, QQQQll, QQQQQl, QQQQQQ. 

In our examples so far we have discussed several families of cooperating co- 
routines and claimed that they generate certain n-tuples, but we haven’t proved 
anything rigorously. A formal theory of coroutine semantics is beyond the scope 
of this paper, but we should at least try to construct a semi-formal demonstration 
that thump is correct. 

The proof is by induction on |if|, the number of chains. If |if| = 1, ehump[k] 
reduces to hump[k], and we can argue by induction on n. The result is obvious 
when n = 1. If n > 1, suppose repeated calls on hump[2] cause 02 ■■■a„ to 
run through the (n — l)-tuples ao, oii, 0 : 2 , • • • , where hump\2] is false when it 
produces at = at-i- Such a repetition will occur if and only if t is a multiple 
of n, because n is the number of distinct (n — l)-tuples with 02 < • • • < a„. We 
know by induction that the sequence has reflective symmetry: aj = a 2 n-i-j for 
0 < j < n. Furthermore, aj+ 2 n = ctj for all j > 0. To complete the proof we 
observe that repeated calls on hump [ 1 ] will produce the n-tuples 



Oaoi 0«i, ..., 0a„_i, lOn, 
lo^n, Qo^n, Qo^n+li ■ • • i Qo:2n— 15 
0a2n, 0o:2n+l, ■■■, 0a3„_i, lasn. 



and so on, returning false every (n -I- 1)®* step as desired. 

If |if| > 1, let E = {ei,...,em}, so that = Cm-i, and suppose that 
repeated calls on ehump[em-i] produce the (tm — l)-tuples ao, ai, « 2 , • • • • Also 
suppose that calls on ehump [em] would set the remaining bits • . • On to the 
(n-k 1 — em)-tuples /3q, /3i, 02, ■ ■ ■ E were empty instead of {ei, . . . , Cm}; this 
sequence I3q, Pi, P 2 , ■■ ■ is like the output of hump. The a and P sequences are 
periodic, with respective periods of length 2M and 2N for some M and N; they 
also have reflective symmetry aj = a 2 M-i-j, Pk = P 2 N-i-k- It follows that 
ehump [em] is correct, because it produces the sequence 
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70) 7i) 72, • ■ • — cto/^o, ao/3i, ao/^w-i, 

a\j3N, ai/3AT+i, ai/32Ar-i, 



CrM-l/3(M-l)AT+l, OiM-l^MN-l, 

0!mPmN, C(mPmN+ 1, aMf3(M+l)N-li 



Ot2M-lP{2M-l)N , tt2M-l/3(2M-l)AT+l, Ct2M-ll^2MN-l, 

which has period length 2MN and satisfies 

'7Nj+k = 0!jP]\fj+k = 0!2M-l-jP2MN-l-Nj-k = 'y2MN-l-Nj-k 



for 0 < j < M and 0 < k < N . 

The patterns output by ebump are therefore easily seen to be essentially the 
same as the so-called reflected Gray paths for radices 62 - 1 - 1 — ei, . . . , Cm+l— 6m-i, 
n -I- 2 — 6m (see [12]); the total number of outputs is 

(e 2 -|- 1 — 6i) . . . (Cm -|- 1 — 6m-l)(n -|- 2 — Cm) ■ 



3 Ups and Downs 

Now let’s consider a “fence” digraph 

which leads to n-tuples that satisfy the up-down constraints 




ai < tt2 > as < U4 >■■■ . 



A reasonably simple set of coroutines can be shown to handle this case, rooted 
at nudge[\]\ 

Boolean coroutine nudge[k\; 
while true do begin 

awakeO : if fc' < n then while nudge [k'\ do return true ; 
a[k] := 1 ; return true ; 

asleepl: if k” < n then while nudge[k"\ do return true', 
return false ; 

awakel: if k” < n then while nudge[k"\ do return true', 
a[k] := 0 ; return true ; 

asleepO: ±f k' < n then while nudge[k'] do return true; 
return false ; 



end. 




194 Donald E. Knuth and Frank Ruskey 



Here {k',k”) = {k + l,k + 2) when k is odd, {k + 2,k + 1) when k is 
even. But these coroutines do not work when they all begin at ‘awakeO’ with 
0102 . . . o„ = 00 ... 0; they need to be initialized carefully. For example, when 
n = 6 it turns out that exactly eleven patterns of odd weight need to be gener- 
ated, and exactly ten patterns of even weight, so a Gray path cannot begin or 
end with an even- weight pattern such as 000000 or 111111. One proper starting 
configuration is obtained if we set oi . . . o„ to the first n bits of the infinite string 
000111000111 . . ., and if we start coroutine nudge[k] at ‘awakeO’ if ak = 0, at 



‘ awake 1’ 


if Ofc = 1. Foi 


' example 


, the sequence 


! of results when 


n = 4 


is 


0001 


Initial configuration 










124 


OOOQ 


nudge[l] = 


nudge [2] 


= nudge[4] = 


true 






124 


0100 


nudge[l] = 


nudge [2] 


= true, nudgt 


,[4] = 


false 




1234 


0101 


nudge[l] = 


nudge [2] 


= nudge\S\ = 


nudg 


e[4] = true 




1234 


0111 


nudge[l] = 


nudge [2] 


= nudge\S\ = 


true. 


nudge [4] = 


: false 


123 


1111 


nudge[l] = 


frrte, nudge\2] = nudgt 


3[3] = 


false 




13 


llQl 


nudge[l] = 


nudge [3] 


= true 








134 


IIQQ 


nudge[l] = 


nudge [3] 


= nudge[4] = 


true 






134 


1100 


nudge[l] = 


nudge [3] 


= nudge[4] = 


false 






134 


1101 


nudge[l] = 


nudge [3] 


= nudge[4] = 


true 






134 


1111 


nudge[\] = 


nudge [3] 


= true, nudgt 


3[4] = 


false 




13 


Qlll 


nudge[l] = 


true, nudge\S\ = false 








123 


QlQl 


nudge[l] = 


nudge [2] 


= nudge[3] = 


true 






1234 


QIQQ 


nudge[l] = 


nudge [2] 


= nudge[3] = 


nudg 


e[4] = true 




1234 


QQOO 


nudge[l] = 


nudge [2] 


= true, nudgt 


3[3] = 


nudge [4] = 


- false 


124 


QQOl 


nudge[l] = 


nudge [2] 


= nudge[4] = 


true 






124 


0001 


nudge[l] = 


nudge [2] 


= nudge[4] = 


false 






124 



Again the cycle repeats with reflective symmetry; and again, some cryptic nota- 
tions appear that will be explained in Section 8. The correctness of nudge will 
follow from results we shall prove later. 



4 The General Case 

We have seen that cleverly constructed coroutines are able to generate Gray 
paths for several rather different special cases of the spider-squishing problem; 
thus it is natural to hope that similar techniques will work in the general case 
when an arbitrary totally acyclic digraph is given. The spider 
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illustrates most of the complications that might face us, so we shall use it as a 
running example. In general we shall assume that the vertices have been num- 
bered in preorder, as defined in [9, Section 2.3.2], when the digraph is considered 
to be a forest (ignoring the arc directions) . This means that the smallest vertex 
in each component is the root of that component, and that all vertex numbers 
of a component are consecutive. Furthermore, the children of each node are 
immediately followed in the ordering by their descendants. The descendants of 
each node k form a subspider consisting of nodes k through scope(/c), inclusive; 
we shall call this “spider fc.” For example, spider 2 consists of nodes {2, 3,4, 5}, 
and scope(2) = 5. Our sample spider has indeed been numbered in preorder, 
because it can be drawn as a properly numbered tree with directed branches: 




The same spider could also have been numbered in many other ways, because 
any vertex of the digraph could have been chosen to be the root, and because 
the resulting trees can be embedded several ways into the plane by permuting 
the children of each family. 

Assume for the moment that the digraph is connected; thus it is a tree with 
root 1. A nonroot vertex x is called positive if the path from 1 to cc ends with 
an arc directed towards x, negative if that path ends with an arc directed away 
from X. Thus the example spider has positive vertices {2, 3, 5, 6, 9} and negative 
vertices {4, 7, 8}. 

Let us write x -^* y if there is a directed path from cc to j/ in the digraph. 
Removing all vertices x such that x —>■* 1 disconnects the graph into a number 
of pieces having positive roots; in our example, the removal of {1,8} leaves 
three components rooted at {2,6,9}. We call these roots the positive vertices 
near 1, and we denote that set by U\. Similarly, the negative vertices near 1 are 
obtained when we remove all vertices y such that 1 y; the set of resulting 
roots, denoted by Vi, is {4, 7, 8} in our example, because we remove {1, 2, 3, 5, 6}. 

The relevant bit patterns ai ... a„ for which oi = 0 are precisely those that 
we obtain if we set aj = 0 whenever j —>■* 1 and if we supply bit patterns for 
each subspider rooted at a vertex of Ui. Similarly, the bit patterns for which 
oi = 1 are precisely those we obtain by setting Ofc = 1 whenever 1 k and 
by supplying patterns for each subspider rooted at a vertex of Vi. Thus if Uk 
denotes the number of bit patterns for spider k, the total number of suitable 
patterns oi . . . a„ is n«G( 7 i + O^gVi 

The sets Uk and Vk of positive and negative vertices near k are defined in 
the same way for each spider k. 
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Every positive child of k appears in Uk, and every negative child appears 
in Vk- These are called the principal elements of Uk and Vk- Every nonprincipal 
member oi Uk is a member of Uy for some unique principal vertex v of Vk- 
Similarly, every nonprincipal member of Vk is a member of Vu for some unique 
principal vertex u of Uk- For example, the principal members of U\ are 2 and 6; 
the other member, 9, belongs to Us, where 8 is a principal member of V\. 

We will prove that the bit patterns oi . . . a„ can always be arranged in a 
Gray path such that bit oi begins at 0 and ends at 1, changing exactly once. 
By induction, such paths exist for the n„ patterns in each spider u for u G Ui- 
And we can combine such paths into a single path that passes through all of the 
riuet/i ways to combine those patterns, using a reflected Gray code analogous 
to the output of ebump in Section 3 above. Thus, if we set = 0 for all k such 
that k 1, we get a Gray path Pi for all suitable patterns with m = 0. 
Similarly we can construct a Gray path Qi for the IltieVi suitable patterns 
with oi = 1. Thus, all we need to do is prove that it is possible to construct Pi 
and Qi in such a way that the last pattern in Pi differs from the first pattern 
of Qi only in bit oi. Then Gi = (Pi,Qi) will be a suitable Gray path that 
solves our problem. 

For example, consider the subspiders for Ui = {2,6,9} in the example spi- 
der. An inductive construction shows that they have respectively (n 2 ,ne,ng) = 
(8,3,2) patterns, with corresponding Gray paths 

Ga = 0000,0001,0101,0100,0110,0111,1111,1101; 

Ge = 00 , 10 , 11 ; 

Gg = 0,l. 

We obtain 48 patterns Pi by setting ai = as = 0 and using Ga for aaa 304 a 5 , 
Ge for 0607 , and Gg for og, taking care to end with oa = oe = 1. Similarly, the 
subspiders for Vi = {4,7,8} have ( 714 , 777 , ng) = (2,2,3) patterns, and paths 

G4 = 0,1; 

G7 = 0,1; 

Gs = 00,01,11. 

We obtain 12 patterns Qi by setting oi = oa = 03 = 05 = og = 1 and 
using G 4 for 04 , G 7 for 07 , and Gs for ogog, taking care to begin with ag = 0. 
Gombining these observations, we see that Pi should end with 011011100, and 
Qi should begin with 111011100. 

In general, the last element of Pk and the first element of Qk can be deter- 
mined as follows: For all children j of k, set aj . . . agcope(j) to the last element 
of the previously computed Gray path Gj if j is positive, or to the first element 
of Gj if j is negative. Then set Ofc = 0 in Pk, ak = 1 in Qk- It is easy to 
verify that these rules make aj = 0 whenever j —>■* k, and aj = 1 whenever 
k j, for all j such that k < j < scope(fc). A reflected Gray code based on 
the paths Gy for u G Uk can be used to construct Pk ending at the transition 
values, having ak = 0 ; and Qk can be constructed from those starting values 
based on the paths Gy for v G Vk, having Ofc = 1. Thus we obtain a Gray path 

Gfc = {Pk, Qk)- 
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We have therefore constructed a Gray path for spider 1, proving that the 
spider-squishing problem has a solution when the underlying digraph is con- 
nected. To complete the construction for the general case, we can artificially 
ensure that the graph is connected by introducing a new vertex 0, with arcs 
from 0 to the roots of the components. Then Pq will be the desired Gray path, 
if we suppress bit oq (which is zero throughout Pq)- 

5 Implementation via Coroutines 

By constructing families of sets Uk and Vk and identifying principal vertices in 
those sets, we have shown the existence of a Gray path for any given spider- 
squishing problem. Now let’s make the proof explicit by constructing a family 
of coroutines that will generate the successive patterns oi . . . a„ dynamically, as 
in the examples worked out in Sections 1-3 above. 

First let’s consider a basic substitution or “plug-in” operation that applies to 
coroutines of the type we are using. Gonsider the following coroutines X and Y : 

Boolean coroutine X ; 
while true do begin 

while A do return true ; 
return false ; 

while B do return false ; 
if C then return true ; 
end; 

Boolean coroutine Y ; 
while true do begin 

while X do return true ; 

return Z ; 

end. 

Here X is a more-or-less random coroutine that invokes three coroutines A, B, 
C] coroutine Y has a special structure that invokes X and an arbitrary coroutine 
Z ^ X,Y. Glearly Y carries out essentially the same actions as the slightly faster 
coroutine XZ that we get from X by substituting Z wherever X returns false: 

Boolean coroutine XZ ; 
while true do begin 

while A do return true ; 
return Z ; 

while B do return Z ; 
if C then return true ; 
end. 

This plug-in principle applies in the same way whenever all return state- 
ments of X are either ‘return true’ or ‘return /aZse’. And we could cast XZ into 
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this same mold, if desired, by writing ‘if Z then return true else return 
false' in place of ‘return Z'. 

In general we want to work with coroutines whose actions produce infinite 
sequences oi, a 2 , ■ • • of period length 2M, where {um, • ■ • , Q; 2 M-i) is the reverse 
of (ao) ■ • ■ ) ctm-i), and where the coroutine returns false after producing at if 
and only if t is a multiple of M. The proof at the end of Section 2 shows that a 
construction like coroutine Y above, namely 

Boolean coroutine AtimesB ; 
while true do begin 

while B do return true ; 

return A; 

end 

yields a coroutine that produces such sequences of period length 2MN from 
coroutines A and B of period lengths 2M and 2N , when A and B affect disjoint 
bit positions of the output sequences. 

The following somewhat analogous coroutine produces such sequences of pe- 
riod length 2{M + N): 

Boolean coroutine AplusB ; 
while true do begin 

while A do return true ; 
a[l] := 1; return true; 
while B do return true ; 
return false ; 
while B do return true ; 
a[l] := 0 ; return true ; 
while A do return true ; 
return false ; 
end. 

This construction assumes that A and B individually generate reflective periodic 
sequences a and (3 on bits 02 . . . a„, and that = /3o- The first half of AplusB 
produces 

Ooo, ■•■5 OttM-l, 3Po, ■■■, 3 Pn-1, 

and returns false after forming 1/3 jv (which equals 1/3 at-i). The second half 
produces the n-tuples 

1(3n, ■■■, 1/32AT-1, 0«M, 0a2M-l, 

which are the first M + N outputs in reverse; then it returns false , after forming 
0 q; 2M (which equals Oao)- 

The coroutines that we need to implement spider squishing can be built up 
from variants of the primitive constructions for product and sum just mentioned. 
Consider the following coroutines gen[V\, . . . , gen[n\, each of which receives an 
integer parameter I whenever being invoked: 
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Boolean coroutine gen[k]{l)', integer 1; 
while true do begin 

awakeO:if maxu[k]^Q then while gen[maxu[k\\(k) do return true; 
a[k] := 1; return true; 

asleepl:if maxv[k]^0 then while gen[maxv[k]]{k) do return true; 
if prev[k] >l then return gen[prev[k]]{l) else return false; 

awakel:if maxv[k]=f^0 then while gen[maxv[k]]{k) do return true; 
a[k] := 0 ; return true ; 

asleepO:if maxu[k]y^0 then while gen[maxu[k]]{k) do return true; 
if prev[k] >l then return gen[prev[k]]{l) else return false; 

end. 

Here maxu[k] denotes the largest element of C/fc U {0}, and prev[k] is a function 
that we shall define momentarily. This function, like the sets Uk and 14, is 
statically determined from the given totally acyclic digraph. 

The idea of ^prev' is that all elements of Ui can be listed as u, prev[u], 
prev [prew[u]], . . . , until reaching an element < /, if we start with u = maxu[l]. 
Similarly, all elements of Vi can be listed as v, prev[v], prev [preu['u]] , . . . , while 
those elements exceed /, starting with v = maxv[l]. The basic meaning of gen[k] 
with parameter I is to run through all bit patterns for the spiders u < k in Up 
if A: is a positive vertex, or for the spiders v < k in Vp ii vertex k is negative. 

The example spider of Section 4 will help clarify the situation. The following 
table shows the sets Uk, Vk, and a suitable function prev[k], together with some 
auxiliary functions by which prev [fc] can be determined in general: 



k 


scope(fc) 


Uk 




prev [fc] 


ppro(fc) 


npro(fc) 


1 


9 


{2,6,9} 


{4,7,8} 


0 


1 


0 


2 


5 


{3,5} 


{4} 


0 


2 


0 


3 


4 


0 


{4} 


0 


3 


0 


4 


4 


0 


0 


0 


3 


4 


5 


5 


0 


0 


3 


5 


0 


6 


7 


0 


{7} 


2 


6 


0 


7 


7 


0 


0 


4 


6 


7 


8 


9 


{9} 


0 


7 


1 


8 


9 


9 


0 


0 


6 


9 


8 



If u is a positive vertex, not a root, let vi be the parent of u. Then if v\ is 
negative, let V 2 be the parent of v\, and continue in this manner until reaching 
a positive vertex vt, the nearest positive ancestor of vi. We call Vt the positive 
progenitor of vi, denoted ppro(ui). The main point of this construction is that 
u G Uk ii and only if k is one of the vertices {vi,V 2 , ■ ■ ■ ,vt}. Consequently 

Uk = C/i n {fc, fc + 1, . . . ,scope(fc)} 

if I is the positive progenitor of k. Furthermore Uk and Uk' are disjoint whenever 
k and k' are distinct positive vertices. Therefore we can define prev [u] for all 
positive nonroots u as the largest element less than u in the set Uk U {0}, where 
k = ppro(parent(u)) is the positive progenitor of tt’s parent. 
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Every element also has a negative progenitor, if we regard the dummy vertex 
0 as a negative vertex that is parent to all the roots of the digraph. Thus 
we define prev [v] for all negative v as the largest element less than v in the 
set Vk U {0}, where k = npro(parent(u)). 

Notice that 9 is an element of both Ui and Us in the example spider, so both 
gen[9]{l) and gen[9]{8) will be invoked at various times. The former will invoke 
5en[6](l), which will invoke 5en[2](l); the latter, however, will merely flip bit og 
on and off, because prev [9] does not exceed 8. There is only one coroutine gen [9]; 
its parameter I is reassigned each time gen [9] is invoked. (The two usages do not 
conflict, because gen^]{l) is invoked only when oi = 0, in which case og = 0 
and gen[8] cannot be active.) Similarly, gen[4\ can be invoked with / = 1,2, or 
3; but in this case there is no difference in behavior because prev [4] = 0. 

In order to see why gen [k] works, let’s consider first what would happen if its 
parameter I were oo, so that the test ^prev[k] > V would always be false. In such 
a case gen[k] is simply the AplusB construction applied to A = gen[maxu[k]]{k) 
and B = gen[maxv[k]]{k). 

On the other hand when I is set to a number such that k G Ui or k G Vi, 
the coroutine gen[k] is essentially the AtimesB construction, because it results 
when Z = gen[prev[k]]{l) is plugged in to the instance of AplusB that we’ve 
just discussed. The effect is to obtain the Cartesian product of the sequence 
generated with I = oo and the sequence generated by gen[prev[k]]{l). 

Thus we see that ‘if maxu[k] ^ 0 then while gen[maxu[k]]{k) do return 
trae’ generates the sequence Pk described in Section 4, and ‘if maxv[k] yf 0 
then while gen[maxv[k]]{k) do return true' generates Qk- It follows that 
gen[k]{oo) generates the Gray path Gk- And we get the overall solution to our 
problem, path Pq, by invoking the root coroutine gen[maxu[9\\{9) . 

Well, there is one hitch: Every time the AplusB construction is used, we 
must be sure that coroutines A and B have been set up so that the last pattern 
of A equals the first pattern of B. We shall deal with that problem in Section 6. 

In the unconstrained case, when the given digraph has no arcs whatsoever, we 
have Uo = {I, ■ ■ ■ ,n} and all other U's and E’s are empty. Thus prev [k] = k—1 
for 1 < fc < n, and gen[k]{9) reduces to the coroutine poke[k] of Section 1. 

If the given digraph is the chain I ^ 2 ^ ^ n, the nonempty U's and 

E’s are [/fc = {fc + 1} for 0 < fc < n. Thus prev[k] = 0 for all k, and gen[k]{l) 
reduces to the coroutine bump [fc] of Section 2. Similar remarks apply to cobump, 
mbump, and ebump. 

If the given digraph is the fence I^2^3^4^---,we have Uk = {k'} 
and Vk = {k"} for I < /c < n, where {k',k") = (k + l,k + 2) if k is odd, 
{k + 2,k + 1) if k is even, except that Un-i = 0 if n is odd, Vn-i = 0 if n is 
even. Also Uq = {!}. Therefore prev[k] = 0 for all k, and gen[k]{l) reduces to 
the coroutine nudge[k] of Section 3. 

6 Launching 

Ever since 1968, Section 1.4.2 of The Art of Computer Programming [9] has 
contained the following remark: “Initialization of coroutines tends to be a lit- 
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tie tricky, although not really difficult.” Perhaps that statement needs to be 
amended, from the standpoint of the coroutines considered here. We need to 
decide at which label each coroutine gen[k] should begin execution when it is 
first invoked: awakeO, asleepl, awakel, or asleepO. And our discussion in Sec- 
tions 3 and 4 shows that we also need to choose the initial setting of oi . . . a„ 
very carefully. 

Let’s consider the initialization of oi . . . a„ first. The reflected Gray path 
mechanism that we use to construct the paths Pk and Qk, as explained in Sec- 
tion 4, complements some of the bits. If, for example, Uk = {ui,U2,--- ,Um}, 
where ui < U2 < • • • < Um, path Pk will contain n„,nu2 . . . bit patterns, and 
the value of bit at the end of Pk will equal the value it had at the beginning if 
and only if is even. The reason is that subpath is traversed 

nuinu2 ■ ■ ■nui_i times, alternately forward and backward. 

In general, let 

Sjk = n„, if j G Uk; Sjk = riy, if j G 14. 

u<j v<j 

uGUk v^Vk 

Let ajk and LOjk be the initial and final values of bit aj in the Gray path Gk for 
spider k, and let Tjk be the value of Uj at the transition point (the end of Pk and 
the beginning of Qk)- Then akk = 0, tOkk = 1, and the construction in Section 4 
defines the values of aik,Tik, and Uik for k <i < scope(/c) as follows: Suppose i 
belongs to spider j, where j is a child of k. 

— If j is positive, so that j is a principal element of Uk, we have Tik = tOij, 
since Pk ends with Uj = 1. Also atk = oJij if Sjk is even, aik = ocij if 
Sjk is odd. If k i we have tOik = 1; otherwise i belongs to spider f , 

where j' is a nonprincipal element of 14 . In the latter case ojik = onji if 
ujj/j + Sj'k is even, otherwise tOik = tOij' ■ (This follows because tOj/j = Tj>k 
and ujjik = {Tj'k + Sj'k) mod 2.) 

~ If j is negative, so that j is a principal element of 14, we have Tik = ocij, 
since Qk begins with aj = 0. Also oJik = oiij if Sjk is even, ujik = tOij if Sjk 
is odd. If i k we have aik = 0; otherwise i belongs to spider j', where / 
is a nonprincipal element of Uk- In the latter case aik = oiij' if aj'j -I- Sj'k is 
even, otherwise aik = ^ij> - 

For example, when the digraph is the spider of Section 4, these formulas yield 



k 


nk 


Initial bits ajk 


Transition bits Tjk 


Final bits tOjk 


9 


2 


ag 


= 0 




1 


8 


3 


asag 


= 00 




11 


7 


2 


ay 


= 0 




1 


6 
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OeOy 


= 00 


*0 


11 


5 


2 


05 


= 0 




1 


4 


2 


04 


= 0 




1 


3 


3 


0304 


= 00 


tO 


11 


2 


8 


02030405 


= 0000 


till 


1101 


1 


60 


0102 . . . 09 


= 000001100 *11011100 


111111100 
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Suppose j is a negative child of fc. If n„ is odd for all elements u of Uk that 
are less than j, then Sij + Sik is even for all i G Uj, and it follows that aik = 
for j < i < scope(j). (If i is in spider f , where j' € Uj C Uk, then aik is or 
u>ij/ according as aj'j + 5j/k is even or odd, and is 0 ;^/ or according as 
aj'j + Sjij is even or odd; and we have 6jik = Sj>j mod 2.) On the other hand, 
if Uu is even for some u & Uk with u < j, then Sik is even for all i € Uj, and 
we have aik = otij for j < i < scope (j). This observation makes it possible to 
compute the initial bits oi . . . a„ in 0{n) steps (see [13]). 

The special nature of vertex 0 suggests that we define Sjo - 1 for I < j < n, 
because we use path Pq but not Qo- This convention makes each component of 
the digraph essentially independent. (Otherwise, for example, the initial setting 
of oi . . . a„ would be 01 ... 1 in the trivial “pofce” case when the digraph has no 
arcs.) 

Once we know the initial bits, we start gen[k] at label awakeO if Ofc = 0, at 
label awake 1 if = 1. 

7 Optimization 

The coroutines gen[l], ..., gen[n] solve the general spider-squishing problem, 
but they might not run very fast. For example, the bump routine in Section 2 
takes an average of about n/2 steps to decide which bit should be changed. We 
would much prefer to use only a bounded amount of time per bit change, on the 
average, and this goal turns out to be achievable if we optimize the coroutine 
implementation. 

A brute-force implementation of the gen coroutines, using only standard 
features of Algol, can readily be written down based on an explicit stack and a 
switch declaration: 

Boolean val ; comment the current value being returned; 
integer array stack[Q : 2 * n] ; comment saved values of k and k, 
integer k, 1; comment the current coroutine and parameter; 
integer s; comment the current stack height; 
switch sw := pi, p2, p3, p4, p5, p6, p7, p8, p9, plO, pll; 
integer array pos [0 : n] ; comment coroutine positions; 

( Initialize everything ) ; 
pi: if maxu[k] ^ 0 then begin 
invoke ( maxu [k],k,2)\ 
p2: if val then ret(l); 
end; 

a[k] := 1; val := true; ret{3); 
p3 : if maxv [fc] yf 0 then begin 
invoke ( maxv [fc] , fc , 4) ; 
p4: if val then ret (3); 
end; 
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if prev[k] > I then begin 
invoke {prev [fc] , 1, 5) ; 
p5: ref (6); 
end 

else begin val := false ; ref (6); end; 
p6 : if maxv[k] yf 0 then begin 
invoke ( maxv [A:] , /c , 7) ; 
p7 : if val then ref (6); 
end; 

a[k] := 0; val := true; ref (8); 
p8 : if maxu [k] yf 0 then begin 
invoke ( maxu [fc] , A: , 9) ; 
p9: if val then ref (8); 
end; 

if prev[k] > I then begin 
invoke {prev [k],l, 10) ; 
plO: ref(l); 
end 

else begin val := false ; ref(l); end; 
pll : ( Actions of the driver program when fc = 0 ); 

Here invoke {newk , newl , j) is an abbreviation for 

pos[k]:=j; sfocA:[s] := fc; sfacA: [s + 1] := f ; s:=s + 2; 
k:=newk; I := newl ; go to sw;[pos[A:]] 

and ref(j) is an abbreviation for 

pos [k] := j ; s := s — 2; 

I := stack[s + 1]; A: := sfacA: [s] ; go to s?r[pos[A:]]. 

We can streamline the brute-force implementation in several straightforward 
ways. First we can use a well-known technique to simplify the “tail recursion” 
that occurs when invoke is immediately followed by ref (see [11, example 6a]): 
The statements Hnvoke{prev[k],l,b); p5: ref (6)’ can, for example, be replaced 

by 

pos[k]:=6; k := prev[k]; go to sw; [pos [A:]]. 

An analogous simplification is possible for the constructions of the form 
‘while A do return true' that occur in gen[k]. For example, we could set 
things up so that coroutine A removes two pairs of items from the stack when it 
returns with val = true, if we first set pos [A:] to the index of a label that follows 
the while statement. More generally, if coroutine A itself is also performing 
such a while statement, we could allow return statements to remove even more 
than two pairs of stack items at a time. Details are left to the reader. 
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8 The Active List 

The gen coroutines of Section 5 perform 0{n) operations per bit change, as they 
pass signals back and forth, because each coroutine carries out at most two lines 
of its program. This upper bound on the running time cannot be substantially 
improved, in general. For example, the hump coroutines of Section 2 typically 
need to interrogate about trolls per step; and it can be shown that the nudge 
coroutines of Section 3 typically involve action by about cn trolls per step, where 
c= (5 + ^/5)/10 « 0.724. (See [9, exercise 1.2.8-12].) 

Using techniques like those of Section 7, however, the gen coroutines can 
always be transformed into a procedure that performs only 0(1) operations 
per bit change, amortized over all the changes. A formal derivation of such a 
transformation is beyond the scope of the present paper, but we will be able to 
envision it by considering an informal description of the algorithm that results. 

The key idea is the concept of an active list, which encapsulates a given stage 
of the computation. The active list is a sequence of nodes that are either awake 
or asleep. If j is a positive child of k, node j is in the active list if and only if 
fc = 0 or Ofc = 0; if j is a negative child of k, it is in the active list if and only if 
Qk — 1- 

Examples of the active list in special cases have appeared in the tables illus- 
trating bump in Section 2 and nudge in Section 3. Readers who wish to review 
those examples will find that the numbers listed there do indeed satisfy these 
criteria. Furthermore, a node number has been underlined when that node is 
asleep; bit Oj has been underlined if and only if j is asleep and in the active list. 

Initially ai . . .a„ is set to its starting pattern as defined in Section 6, and 
all elements of the corresponding active list are awake. To get to the next bit 
pattern, we perform the following actions: 

1. Let k be the largest nonsleeping node on the active list, and wake up all 
nodes that are larger. (If all elements of the active list are asleep, they all 
wake up and no bit change is made; this case corresponds to gen[maxu[Q\\{Q) 
returning false .) 

2. If Ofc = 0, set Ofc to I, delete fc’s positive children from the active list, 
and insert k’s negative children. Otherwise set Uk to 0, insert the positive 
children, and delete the negative ones. (Newly inserted nodes are awake.) 

3. Put node k to sleep. 

Again the reader will find that the hump and nudge examples adhere to this 
discipline. 

If we maintain the active list in order of its nodes, the amortized cost of these 
three operations is 0(1), because we can charge the cost of inserting, deleting, 
and awakening node k to the time when bit Ofc changes. Steps (1) and (2) might 
occasionally need to do a lot of work, but this argument proves that such difficult 
transitions must be rare. 

Let’s consider the spider of Section 4 one last time. The 60 bit patterns that 
satisfy its constraints are generated by starting with m . . . og = 000001100, as 
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we observed in Section 6, and the Gray path Gi begins as follows according to 
the active list protocol: 



000001100 


1235679 


000001101 


1235679 


OOOOOIQOI 


1235679 


OOOOOIQOQ 


1235679 


000000000 


123569 


OOOOOQOOl 


123569 


000010001 


123569 


OOOOIOOOQ 


123569 


000011000 


1235679 



(Notice how node 7 becomes temporarily inactive when og becomes 0.) The 

most dramatic change will occur after the first n 2 neng = 48 patterns, when bit 
oi changes as we proceed from path Pi to path Qi: 

OUQinOO 124679 

111011100 14789 

(The positive children 2 and 6 have been replaced by the negative child 8.) 

Finally, after all 60 patterns have been generated, the active list will be 14789 
and oi . . . og will be lllllllQQ. All active nodes will be napping, but when we 
wake them up they will be ready to regenerate the 60 patterns in reverse order. 

It should be clear from these examples, and from a careful examination of the 
gen coroutines, that steps (1), (2), and (3) faithfully implement those coroutines 
in an efficient iterative manner. 



9 Additional Optimizations 

The algorithm of Section 8 can often be streamlined further. For example, if j 
and j' are consecutive positive children of k and if Vj is empty, then j and j' 
will be adjacent in the active list whenever they are inserted or deleted. We can 
therefore insert or delete an entire family en masse, in the special case that all 
nodes are positive, if the active list is doubly linked. This important special case 
was first considered by Koda and Ruskey [14]; see also [12, Algorithm 7. 2.1. IK]. 

Further tricks can in fact be employed to make the active list algorithm 
entirely loopless, in the sense that 0(1) operations are performed between suc- 
cessive bit changes in all cases — not only in an average, amortized sense. One 
idea, used by Koda and Ruskey in the special case just mentioned, is to use 
“focus pointers” to identify the largest nonsleeping node (see [7] and [12, Algo- 
rithm 7.2.1.1L]). Another idea, which appears to be necessary when both positive 
and negative nodes appear in a complex family, is to perform lazy updates to the 
active list, changing links only gradually but before they are actually needed. 
Such a loopless implementation, which moreover needs only 0(n) steps to initial- 
ize all the data structures, is described fully in [13]. It does not necessarily run 




206 Donald E. Knuth and Frank Ruskey 



faster than a more straightforward amortized 0(1) algorithm, from the stand- 
point of total time on a sequential computer; but it does prove that a strong 
performance guarantee is achievable, given any totally acyclic digraph. 

10 Conclusions and Acknowledgements 

We have seen that a systematic use of cooperating coroutines leads to a general- 
ized Gray code for generating all bit patterns that satisfy the ordering constraints 
of any totally acyclic digraph. Furthermore those coroutines can be implemented 
efficiently, yielding an algorithm that is faster than previously known methods 
for that problem. Indeed, the algorithm is optimum, in the sense that its running 
time is linear in the number of outputs. 

Further work is clearly suggested in the heretofore neglected area of corou- 
tine transformation. For example, we have not discussed the implementation of 
coroutines such as 

Boolean coroutine copoke[k]; 
while true do begin 

if fc < n then while copoke[k + 1] do return true', 
a[k] := 1 — a[k] ; return true ; 

If k < n then while copoke[k + 1] do return true', 

return false ; 

end. 

These coroutines, which are to be driven by repeatedly calling copoke [1], 
generate Gray binary code, so their effect is identical to repeated calls on the 
coroutine poke[n] in Section 2. But copoke is much less efficient, since copoke[V\ 
always invokes copoke[2], ..., copoke[n] before returning a result. Although 
these copoke coroutines look superficially similar to gen, they are not actually a 
special case of that construction. A rather large family of coroutine optimizations 
seems to be waiting to be discovered and to be treated formally. 

Another important open problem is to discover a method that generates the 
bit patterns corresponding to an arbitrary acyclic digraph, with an amortized 
cost of only 0(1) per pattern. The best currently known bound is O(logn), due 
to M. B. Squire [17]; see also [16, Section 4.11.2]. There is always a listing of 
the relevant bit patterns in which at most two bits change from one pattern to 
the next [15, Gorollary 1]. 

The first author thanks Ole-Johan Dahl for fruitful collaboration at the 
University of Oslo during 1972-1973 and at Stanford University during 1977- 
1978; also for sharing profound insights into the science of programming and 
for countless hours of delightful four-hands piano music over a period of more 
than 30 years. The second author thanks Malcolm Smith and Gang (Kenny) Li 
for their help in devising early versions of algorithms for spider-squishing during 
1991 and 1995, respectively. Both authors are grateful to Stein Krogdahl and to 
an anonymous referee, whose comments on a previous draft of this paper have 
led to substantial improvements. 
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Abstract. ALGOL60 introduced the block level strncture with its char- 
acteristic static binding and visibility scopes of identifiers, phenomena 
known before in predicate logics and A-calculi outside programming. 
Misinterpretations and misimplementations of originally intended static 
scope semantics of ALGOL60 and Lisp have seduced language designers 
and practitioners to a notion of dynamic scope semantics which sup- 
presses identifier renamings during program execution. Dynamic scoping 
has become popular above all in object-oriented programming, although 
the inventors of the latter and authors of Simula 67, O.-J. Dahl and 
K. Nygaard, explicitly based their ideas on ALGOL60 and static scop- 
ing. And there are follower languages which successfully combine object- 
orientation and static binding. The present article demonstrates that the 
implementation problems around the especially flexible and useful con- 
cept of many level or skew prefixing (inheritance) can well be solved, 
shown by LOGLAN’88, an extension of Simula 67. 



1 Introduction: Origins of Static and Dynamic 
Identifier Binding 

The higher programming language ALGOL60 introduced several remarkable 
software concepts. One is the block concept, essentially advocated by K. Samelson 
who was a member of the international ALGOL58- and ALGOL60-committees 
[PeS58, Nau60]. The block level structure and its characteristic storage allo- 
cation scheme are most important contributions of Samelson to programming 
science and technology [Sam55]. ALGOL58 [PeS58] and FORTRAN [Bac57] did 
not yet speak about binding and visibility scopes of identifiers, although these 
phenomena were known in predicate logics and A-calculi since the 1930s [Her61]. 

ALGOL60’s block concept has brought an essential syntactical and seman- 
tical clarification of the procedure concept. ALGOL60-procedures evolved from 
ALGOL58’s notions procedure and do-statement. ALGOL-like, static binding 
of identifiers in ALGOL60’s operational copy rule semantics was expressed by 
the requirement that procedure body and parameter replacements had to avoid 
binding violations (identifier clashes) by appropriate bound identifier renam- 
ings. The ALGOL60-report’s formulations for language semantics, especially for 
semantics of procedures (function procedures and resultless procedures) would 
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have become much clearer to programmers and compiler constructors if the re- 
port had explicitly hinted at the a- and /3-reductions in A-calculi known already 
at that time. Such a hint would have helped to avoid many unfortunate devel- 
opments of language definitions, of compilers and of run time systems, not only 
for ALGOL60, but also for many successor languages. 

Samelson pointed out the idea of blocks and their characteristic data stor- 
age behaviour already in [Sam55]. He spoke about partial programs as open 
subprograms and library programs as closed subprograms. On the one hand 
he described how, during translation and evaluation of arithmetic formulas, in- 
termediate results had to be stored in auxiliary storage cells where last stored 
results became available again first. The ground for that phenomenon was the 
left to right break down of formulas; the leftmost break down feasibilities were 
to be envisaged again and again; such proceeding is justified because evalua- 
tion of arithmetic formulas, also those known from school with their infix no- 
tations, bracket savings and priority rules, is confluent. The notation number 
cellar Bauer- Samelsonscher ZahlkelleT^') for pulsating of intermediate results 
appeared in the patent specification [BaS57] for the first time and afterwards in 
the article “Sequential Formula Translation” [SaB59]. On the other hand, also 
in 1955, Samelson described how run time pulsating of intermediate results ex- 
tended to data storage cells for open and closed subprograms what was justified 
for confluence reasons as well. Subprograms had to cooperate with an indica- 
tion of momentarily free storage entered in a fixed variable named beginning free 
storage. 

With explicit references to [SaB59] E. W. Dijkstra described in ’’Recursive 
Programming" [Dij60] how the Bauer-Samelson-number cellar was to be ex- 
tended towards a run time staek for blocks and procedures of ALGOL60. The 
variable beginning free storage was now named stack pointer, every procedure call 
generated a procedure incarnation for which an information unit with places for 
procedure link, local parameters, local variables and intermediate results was en- 
tered in the run time stack. In the procedure link Dijkstra established the return 
address of the procedure P called, the dynamic pointer pointing at the youngest 
preceding, not yet completed, incarnation (of that procedure Q wherein the call 
of P occured) and - what is crucial - the so called static pointer pointing at the 
most recent, not yet completed, incarnation of that first (i.e. smallest) procedure 
R lexicographically enclosing P. The static pointer is the instrument to access 
informations about global procedure parameters of P. 

Unfortunately, Dijkstra’s most-recent-prescription for static pointers does 
not fit ALGOL60’s copy rule semantics and static binding: We can construct 
ALGOL60-programs which do not satisfy the so called most-recent-property, 
which means, there is a static pointer in a (corrected) run time system which 
does not point to the most recent incarnation of procedure R, but to one fur- 
ther down towards the stack bottom [GHL67]. There are astonishingly short 
programs with just two nested procedures, with procedure identifiers as formal 
and actual parameters and with formal procedure calls violating the most-recent- 
property as P. Kandzia demonstrated [Kan74]. Dijkstra’s implementation causes 
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unexpected changes of identifier meanings during execution, changes which the 
programmer is hardly able to pursue and understand so that she/he is surprised 
by curious final program results. If such changes of meaning are desired by lan- 
guage semantics definition then we speak of dynamic binding or dynamic scope 
semantics. Even the involved program example GPS (General Problem Solver) 
worked out in [RaR64] to demonstrate name parameter passing is not involved 
enough: GPS satisfies the most-recent-property. 

Dijkstra’s most-recent-prescription how to deal with static pointers has been 
used in implementations and in compiler building text books for ALGOL-like 
programming languages still in more recent years [WiM92] . This has led to dis- 
crepancies between originally intended language semantics and actual program 
executions. In order to avoid disappointments language Ada [IchSO] excluded 
procedures as arguments of procedure calls and language G [KeR78] disallowed 
any procedure nestings. Under these language restrictions static resp. dynamic 
scoping lead to equivalent program computations if the executed wellformed 
programs are distinguished, i.e. different defining identifier occurrences are de- 
noted by different identifiers which, above that, must be different from standard 
ones (Defining occurrences are those places of identifiers in a program where 
their kinds, types etc. are introduced, all other identifiers occurrences are ap- 
plied ones. An occurrence of a free identifier is an applied occurrence not bound 
to any defining occurrence. In a wellformed program every free identifier is to 
be standard). 

There was a further influential publication which involuntarily brought dy- 
namic binding to the attention of programmers. In “Lisp 1.5 Programmer’s Man- 
ual” [McG65] J. McGarthy et al. published two Lisp- written interpreters in order 
to define an operational copy rule semantics of the functional language Lisp. Mc- 
Garthy draw up Lisp as a user friendly setting of A. Ghurch’s (applied) A-calculus 
with its static binding. But programming errors in the interpreters established 
a Lisp-semantics with dynamic binding such that even simple bound renamings 
showed different program results [Hoa90]. Langmaack found the programming 
errors in [McG65] during courses on compiler and run time system construc- 
tion at the University of the Saarland 1970/71. He briefly repaired the Lisp- 
interpreters towards static binding and spoke of natural Lisp-semantics. Later 
the Lisp-community with GommonLisp [Ste84] has acknowledged the virtue of 
ALGOL-like, static binding. 

The wording ’’dynamic binding “ does not mean that this kind of binding 
offers clear advantages or higher potentials over static binding. At run time dy- 
namic binding requires searching processes down the run time stack in order 
to load and store program variables resp. to load static pointers and display 
registers whereas static binding allows direct loadings. Dynamic binding leads 
to regular procedure call trees of programs and so to provable existence of rela- 
tively complete Hoare proof calculi [01d81] whereas static binding may generate 
irregular procedure call trees such that there are no good Hoare proof calculi 
for full ALGOL60 nor ALGOL68 [Wij+69] nor Pascal [JeW75] [Gla79, LaO80]. 
In spite of these good news about dynamic binding program understanding and 
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formulation of procedure pre- and postconditions is more difficult because for 
dynamic scope semantics there do not hold so mature substitution and bound 
renaming theorems as for static scope semantics. 

2 Object-Orientation and Identifier Binding 

Dynamic binding became popular above all in object-oriented programming al- 
though dynamic binding began from misinterpretations and misimplementations 
of originally intended language semantics and although O.-J. Dahl and K. Ny- 
gaard, the creators of the notions object, class, inheritance and of the language 
Simula67, explicitly based their ideas upon ALGOL60 with its block struc- 
ture and static binding [DaN67, DahOla]. Also follower languages like BETA 
[MMPN93] and LOGLAN’88 [KSW88] successfully combine object-orientation 
and static binding in a consistent manner. Gomparatively old languages like AL- 
GOL60 or Pascal allowed already that program parts, which were developed in 
parallel by separated software engineering groups, could be combined by pro- 
cedure encapsulation without any problems. A dynamic binding regime would 
not so easily allow such software engineering practice because it is error prone 
or even impossible without full knowledge of local names in the other groups’ 
program parts. 

As mentioned before, Simula67 already had the inheritance idea incorpo- 
rated, but demanded, for pragmatic reasons, same level inheritance, i.e. every 
inherited class must have the same module nesting level as the inheriting mod- 
ule. LOGLAN as well as BETA strived for many level (skew) inheritance so that 
programmers were not forced to write unnecessary class copies by hand and were 
enabled to install class libraries more flexibly. The serious problems how to de- 
fine clear language semantics for many level inheritance under a static binding 
regime and how to establish efficient implementations were not yet foreseen in 
1967 [DahOlb]. 

Goal of the present article is to show that these problems can well be solved. 
As a demonstration instrument we take LOGLAN’88, which extends Simula67 
by prefixing at many levels, by inheriting in procedures, functions, processess, by 
concurrency, exceptions and signals and has been developed and implemented 
by the informatics research group around A. Kreczmar (f) and A. Salwicki at 
the University of Warsaw who are wellknown for their foundational work on 
algorithmic logic. LOGLAN’s development began in the later 1970s and took 
its way via forerunners LOGLAN-77 and LOGLAN-82. We would like to give 
an informal description of the following more detailed sections 3 to 6 on how 
LOGLAN has solved the addressed problems: 

For LOGLAN we may define an operational copy rule semantics - which is 
a variant of structural operational semantics - with static binding (scoping) as 
for other ALGOL-like languages. Not only procedure calls and object genera- 
tions invoke copy rule applications, elimination of inheritances {prefixings) does 
so as well with which modules {units) like classes, blocks and procedures may be 
adhered with. This style of semantics definition is plainly at the high program- 



Consistency of Inheritance in Object-Oriented Languages 213 



ming language level without any references to implementations nor processors 
[KKSL84], 

The guiding idea for efficient implementation is that inheritance elimination 
may be imagined in a different semantics preserving way: Classes are transformed 
to procedures and inheriting modules are attached by new local procedures whose 
formal parameters are exactly those identifiers which can be reached via the 
inheritance (prefix) chain of the inheriting module. I.o.w.: Object orientation by 
classes and inheritances offers both a great structuring method and a pleasant 
shorthand (parameters saving) notation for ALGOL-programs. 

Java’s way how to define and treat semantics of inner classes and their many 
level prefixings by converting inner classes to toplevel ones is a different proceed- 
ing. The relations to static resp. dynamic scoping philosophies are to be clarified 
[Sun97, SaW02]. [SSBOl] says explicitly that nested and inner classes are not 
treated. 

Due to [DiJ60] efficient block and procedure implementation for ALGOL can 
be done by the help of static pointer chains and display registers. All applied 
identifier occurrences which are bound to the same defining occurrence and, 
under static scoping, mean the same thing are coupled to the same register 
which is fixed by the module nesting level of the defining occurrence. Because 
of Simula67’s same level inheritance regime ALGOL’s display register allocation 
scheme is holding for Simula67 as well. The most pleasant and important impli- 
cation is that no display register reloadings are necessary as long as a run time 
computation procedes from member to member of a whole prefix chain and does 
not leave that chain. 

This ALGOL-Simula67-display register allocation scheme gets inadequate 
as soon as many level inheritance comes into scene. But the efficiency gaining 
Simula67-no-reloading property should urgently pertain for many level prefix- 
ing. There might be more display registers necessary than the maximal level of 
module nestings . So S. Krogdahl [Kro79] has proposed to optimize the BETA- 
codegenerator so that the minimal possible display register number is determined 
at translation time. [KKSL84] prove by systematic display register permuta- 
tions that this minimal number is exactly the maximal module nesting level 
of the given program as we know from ALGOL60 or Simula67. A. Kreczmar 
and M. Warpechowski [KLKW85, KKLSW87] developed an elegant theory of 
L-algebras and their implementations for which LOGLAN-programs are mod- 
els. Theory and implementation may be viewed as results of deliberations about 
what program language semantics with static scoping truly means. 



3 Syntax and Static Semantics of MiniLOGLAN 

In order to demonstrate proper specification of syntax, static semantics (context 
conditions) and dynamic semantics of programming languages with classes, in- 
heritance (prefixing) and static scoping we present in appendix A a contextfree- 
like grammar for MiniLOGLAN which is a sublanguage of LOGLAN. So an 
implementation of the latter is also one of MiniLOGLAN. Its purpose is to ab- 
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stract from less important details and to concentrate on the problem of meaning 
of identifiers in languages that have classes, objects, nesting of classes and inher- 
itance without Simula 67’s restrictions. So insights in MiniLOGLAN will show 
up ways which developments of other languages like Java can take. 

Modules are blocks, procedures and classes. A module can be prefixed by at 
most one class; so we have inheritance or prefix chains. Procedures need not nec- 
essarily be prefixed. Their prefixing could be modeled by prefixing their bodies 
written as blocks if many level prefixing and static scoping with its bound iden- 
tifier renamings are envisaged. A class initialization new ^ can be implemented 
by a simple prefixed block 



inh ^ block end 

with empty declaration and statement lists. The statement list A of a class 
body has to contain exactly one control statement inner with its prologue Si 
and epilogue S 2 : 

S = Si inner A2. 

Should there be no explicit inner then inner is imagined to be the final state- 
ment of S with an empty epilogue S2 ■ 

There is a conceptual difference between a substring cr of a program tt (tt = 
a a uj) and of a substring occurrence V in tt , a pair of a and i with i = |a|-|-l. The 
same substring cr may occur several times. That is especially true for identifiers. 
Structured substring occurrences are those which reduce to non-terminal symbols 
in the unambigously associated structure tree of tt. Two structured substring 
occurrences are either disjoint or contained in each other. 

Modules in tt form a tree. They have nesting levels > 1. The program 
itself is the largest module, a block module of level = 1. Every module has 
an associated binding range '"R , the largest substring of which reaches from 
the keyword block resp. class resp. proc to the matching end and which, by 
definition, has the same nesting level Vru = the module. Every structured 

substring and especially every defining occurrence of an identifier inside 
the largest binding range (the associated binding range of tt) has a so called 
environment range '~R = env{^ a) = env(^^) = env(j) which is the smallest range 
which encloses ^cr resp. resp. position j. If program tt is named by ^ then the 
defining occurrence is defined to have level 0, the level of any other defining 
occurrence is that of env(J^) which is > 1. The associated local identifier 
list locidl (f R) of a binding range is the ordered list of all defining identifier 
occurrences with env{^^) = ^R . 

In a wellformed program tt every identifier occurrence must be bound to at 
most one defining occurrence of that same identifier; all freely occurring identi- 
fiers must be standard with a predefined meaning; and all identifier applications 
have to be in type accordance with their associated definitions. So we have to 
establish a partially defined binding function bdfct(i^ which determines the as- 
sociated defining occurrence of an identifier ^ if the searching process starts 
from position i (mostly ^’s applied position) : 
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bdfct{i,^) := 

if i is outside the largest binding range of tt 
then if TT is a block named by ^ 

then 

else undefined fi 
else if ^ occurs in locidl(env(i)) 

then the rightmost entry in that local identifier list 
else if env(i) = has an applied prefix class identifier 
occurrence *77 with I = r — 1 
then bdfctpref (I , ^rj) 
else bdfct fi fi fi 

The auxiliary binding function bdfctpref (i , S) determines the associated 
defining occurrence of identifier f inside a so called prefix chain starting with 
class identifier occurrence *77 . i is the original starting point of the searching 
process for i is needed in case a defining occurrence of f cannot be found in 
the present prefix chain. Furtheron we see: Searching along a prefix chain has 
priority over searching through enclosing binding ranges. Be aware that prefix 
chains can be determined only in connection with the binding function bdfct, not 
in an independent manner. 

bdfctpref {i, 77) := 

if bdfct {l,rf) yields a defining class identifier occurrence ^77 
with its class module and associated binding range ’’i? 

then if f occurs in locidl{^ R) 

then the rightmost entry in this local identifier list 

else if has an applied prefix class identifier occurrence 

r— 

then bdfctpref (i, 
else bdfct , ^) fi fi 
else undefined fi 

If *77 is prefixing the module and *77 = bdfct(l, rf) is identifying class ^'M' 
then this is called the direct prefix module preff^M ). In a wellformed program 
all prefix chains, i.e. successive applications of function pref must be acyclic. 
This additional demand for wellformedness cannot be concluded from existence 
of reasonable identifier binding. 

If bdfct{i,f) = with j yf 1 then there is the smallest module enclosing 
position i resp. occurrence such that is occuring in the local identifier list 
of a module ^ M’ = pref'^{^ M), n > 0 .We call ^ M' the declaring module and 
the vertex module of . 

Wellformed MiniLOGLAN-programs tt open up an important algebraic view, 
it will later help to create display register allocation for efficient static scope 
implementation. Let A4 be the set of all module occurrences ^ M in tt. We have a 
partial nesting function end : Ai —> A4 which makes M a finite tree and a partial 
prefixing function pref : M M which makes A4 a finite forest of finite trees. 
The definition is due to Kreczmar and Warpechowski [KLKW85, KKLSW87] : 
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Definition 3.1: An L-algebra is an algebra L =< At, end, pref, tt > where Ai 
is a non-empty finite set, end and pre/are partial functions defined on A4 into 
At , 7T is an element of At , and the following axioms are satisfied: 

(Al) end('K) is undefined, and for every a € At is end* (a) = tt 
(i.e. 7T is the root of the encZ-tree At); 

(A2) for every a G Ai pref~ (a) is undefined (i.e. prefixing is acyclic); 

(A3) for every a G At if pref (a) is defined then end pref (a) is defined and 
pref enct^ (a) = end pref (a) holds (i.e. if a diagram 



a 



c 

end 



pref 






holds then it can be complemented 



d 

A 

+ 



* 

^ C 

I 



a 



e.g. by vertex module d of identifier which prefixes module a ; c is 
the declaring module of ; vertex module d is the smallest module 
fulfilling the above diagram). 

Theorem 3.2: L =< At, end, pref, tt > is an L-algebra. 



In appendix B we present a wellformed program tti which shows many level 
prefixing. The L-algebra looks as follows 



M 




LI 




applied 



A X defining 

: bdfct 
B X applied 



nesting level 
1 

2 

3 

4 
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7Ti is not distinguished because there are two defining occurrences of x in the 
main parts (i.e. inside the binding ranges, but outside inner ones ) of M and of 
A and two defining occurrences of y in the main parts of LI and of L3. 

A most important notion in L-algebras is that of the uniquely determined 
complement module d = comp(a, b, c) for a triple of modules with b = pref*(a) 
and c = encl*(b) such that diagram 



* 

>C 

A 

* 



holds. The existence of d is resulting from a unique normal form theorem basing 
on axiom (A3). In case c = b then d = a, in case a = b then d = c, in case 
b = pref(a) and c = encl(a) then d = compfa, b, c) is the smallest module 
satisfying diagram 



d 

A 

* 

a 



* 

^ c 

A 

+ 

But be aware that this smallest module property does not hold for comple- 
ment modules in general for b = pref^ (a) and c = encV~ (b ), see a counterexample 
in appendix H of [KKSL84] . For implementation of static scoping with many level 
prefixing the following composition theorem is important: 

Theorem 3.3: Complement module diagrams can be composed horizontally and 
vertically. 

Be aware again: This theorem would not hold if we would have based the defini- 
tion of complement modules on the above mentioned smallest module property. 



d 

A 

+ 

a 



4 Semantics of MiniLOGLAN 

The (dynamic) semantics of programs with prefixing is based on the idea of prefix 
elimination which makes prefix chains shorter. We call this process original prefix 
elimination because in Section 5 we shall discuss a different elimination method. 
Let 7T be a wellformed program. Let in tt a class declaration 



(1) unit rj : inh f class A S end rj 
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or a block 



(2) r] : inh ^ class A E end ry 

be given, prefixed by ^ which identifies a class 

(3) unit ^ : inh class Z\' E'^ inner E '2 end ^ 

We have assumed that this class is again prefixed by what is not necessarily 
the case. 

Prefix elimination replaces class (1) or block (2) by a class (1’) or block (2’) 
in the following way: 

(1’) unit rj : inh class A' E'^ gbegin A E end E '2 end ry 



or 

(2’) rj : inh block Z\' E'^ gbegin A E end E '2 end ry 

If inh is not existent in (3) then inh is not existent in (!’) nor (2’). 

Elimination of prefixes of procedures is done in an analogous way. We see espe- 
cially that replaced modules remain modules of the same kind, namely classes, 
blocks or procedures. 

Lemma 4.1: Original prefix elimination yields a new wellformed program tt' 



orig pref elim 

if 7T is distinguished. Otherwise tt' does not necessarily result to be wellformed, 
not even closed, i.e. tt' shows up free non-standard identifiers. If bound renam- 
ings are allowed and identifier clashes are avoided, e.g. by systematic renaming 
of programs in distinguished ones, then successive prefix elimination preserves 
wellformedness and is confluent. 

If successive original prefix elimination under identifier clash avoidance, i.e. un- 
der static scoping regime, is applied to every prefixed module then (perhaps 
after infinitely many steps) the process ends up with an essentially uniquely de- 
termined (perhaps infinite) program tt" which has only redundant prefixing and 
redundant classes. It is actually sufficing to apply prefix elimination to every 
outermost prefixed module, i.e. outside any other prefixed module (and conse- 
quently outside class ^ itself if ^ is prefixed). 

In appendix C we present a wellformed program tt 2 with a structure of class 
and block modules 
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M 



N 

t 

c 

which has so called recursive prefixing without recursive procedures declared in 
7T2. Recursive prefixing is impossible in Simula67-like programs with their same 
level prefixing. 

If we erase all classes in tt" (because they have got redundant) we have 
a wellformed ALGOL-program. It has a well defined operational resp. deno- 
tational semantics. This is defined to be the (dynamic) semantics of the given 
MiniLOGLAN-program tt. Semantics definition is not hindered by infinity of tt". 

In case we do dynamic scoping, i.e. disallow bound renamings of identifiers, 
and start from wellformed programs tt (which are not distinguished in general) 
then we cannot preserve wellformedness nor achieve confluence. In order to pre- 
serve at least closedness of resulting programs tt', every prefixing class ^ to be 
eliminated must have no prefix itself. Further on, in order to enforce confluence, 
prefix elimination must be applied to outermost prefixed modules only. These 
demands indicate , so to speak, that dynamic scoping leads to less robust seman- 
tics than static scoping does. And both semantics are differing as our program 
example tti in appendix B demonstrates: 

Gomplete elimination of all prefixing in tti and of all classes A, B and G 
yields a program tt'( in appendix D. Static scoping requires some renamings: Of 
X in class M to x , of y in block L3 to y , and of x, newly introduced in block 
L3 by prefix B elimination, to x’. Static scope semantics output of tt" and so by 
definition of tti is 




2.0, 2.0, 3.0. 

For dynamic scoping simply forget renamings in tt". Dynamic scope semantics 
output of and so by definition of tti is 

2.0, 4.0, 4.0. 

Even if you turn tti to a distinguished program tt^*'** (i.e. x in M to ir and y in 
L3 to y ) and do prefix elimination under dynamic scoping you do not arrive at 
the static (nor the dynamic) scope semantics, but to the output 

2 . 0 , 2 . 0 , 2 . 0 , 



see quasi static scope semantics in Section 6.1. 
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5 Prefix Elimination by Transforming to Procedures 

As indicated already: If we deal within MiniLOGLAN only with Simula67-like 
programs tt with their same level prefixing and static scoping regime then succes- 
sive original prefix elimination needs only finitely many steps to reach a program 
■k" where all prefixings, class initializations and class declarations are redundant. 
So the resulting programs tt" may be called truly ALGOL-like. 

Finitely many steps are not sufficing in general MiniLOGLAN. But in any 
case, a “final” tt" may be considered to be an ALGOL-like program, be it finite 
or infinite, it is established with a welldefined semantics. 

But there is a different (new) prefix elimination process by transforming 
classes and prefixed blocks to procedures. This process is always finite. Let tt 
be a distinguished wellformed program. We are allowed to assume there are no 
class initializations nor prefixed procedures in tt. 

Let a non-prefixed class declaration 

unit T] : class A Si inner E2 end 77 

in 7T be given which defines a module in tt . Let 

be the local identifier list locidl(^ M) . inner indicates the only inner-statement 
in the main part of class rj . Then the module above is transformed to 
unit 77 : proc (r]f) 

A 

Si call 77/ (^1 • • - A2 
end 77 

where 777- is a new formal procedure identifier with an appropriate specification 
which we have deleted. It is induced by the declarations of ... ^„ in tt in a well 
known way. 

Now we consider a prefixed class declaration 

unit 77 : inh ^ class A Si inner S2 end 77 
in 7T which defines a module ^ M in tt with its finite prefix chain 
pref~^{^M) < • • • < pref°{^M) ,l > 1, 



and its local identifier lists 

= locidl{pref{^ M)), 

• ■ •*'" Cm = locidl{pref~^{^M)) ■ ■ ■ locidl{pref^(^ M)). 

Then the above module is transformed to 
unit 77 : proc (777-) 

unit 77g : proc (Ci ■ ■ • Cm) 

A 
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Sx call ?7/(Ci ■ ■ ■ Cm Cl ■ ■ ■ Cn) ^2 
end rjg 
call C (%) 

end rj 

where tjf and rjg are new procedure identifiers with appropriate specifications 
which we have deleted. The specifications of ijf and ijg and Ci ' ' ’ Cm in the 
resulting program are induced by the declarations of Ci • • • Cm and Ci ' ' ' C™ in tt. 
A prefixed block is treated similarly: Let 

rj : inh C block A E end rj 

be such a block in tt which defines a module in tt. This block is transformed 
to 

rj : block 

unit rjg : proc (Ci •• - Cm) 

A 

A 

end rjg 
call C iVg) 

end rj . 

The symbols have the same meanings as before. 

Now we should like to sketch a proof why the given MiniLOGLAN-program 
TT and its transformed ALGOL-like program tt are semantically equivalent. Let 
us look at a non-prefixed class 

(1) unit C : class A' E'^ inner E'^ end C 
which is prefix of a block 

(2) rj : inh C block A E end rj 

in TT or in any program at any stage of the successive original prefix elimination 
process. We may assume that program to be distinguished. Let 

*^Cl-->Cn 

be the local identifier list of class C- The translated class and block look as follows 
(1) unit C : proc (C/) (2) ij : block 

A' unit rjg : proc (Ci . ■ . Cn) 

r; CallC/(Cl--.Cn) ^2 ^ 

end C E 

end rjg 
call ^{rjg) 
end rj 

Now we compare original prefix elimination in (1), (2) and copy rule appli- 
cations in (1), (2) . Prefix elimination gives 

rj : block 

A' 

gblock 

A 
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end 



y 

end rj 

and copy rule applications give 



first step: 

rj : block 

unit Tjg : proc (Ci . . - Cn) 



second step: 

T] : block 



unit Tjg : proc (Ci ■ ■ ■ Cn) 
zi 

Z" 

end Tjg 
gbegin 

Z\' 



z\ 

end Tjg 
gbegin 

Z\' 



S[ call TjgiCi, . . . ,Cn) ^2 



gbegin 

zi 



end 

end ij , 



end 




end 

end T] 



We see: Prefix elimination and associated procedure call call f (%) lead to equiv- 
alent program expansions since procedure rjg has become redundant. The other 
three cases 

a block T] prefixed by a prefixed class 
a class r] prefixed by a non-prefixed class 
a class r] prefixed by a prefixed class ^ 
lead to analogous results. 

Theorem 5.1: A given wellformed MiniLOGLAN-program tt and its effectively 
transformed ALGOL-like program where all classes and prefixings have been 
eliminated and replaced by procedure declarations and calls are semantically 
equivalent. 

Let us draw some conclusions from Section 5: By object-orientation via 
classes and inheritances Dahl and Nygaard have created a great program struc- 
turing method. This structuring can be achieved also by a systematic exploita- 
tion of ALGOL-procedure parameter transmission. But object-orientation offers 
a very pleasant shorthand notation for ALGOL-programs which comes along 
with drastic parameter savings. 

Since many level prefixing is no hindrance the new prefix elimination tech- 
nique in Section 5 is suggesting a program implementation method by use of 
display registers which is as efficient as for Simula67 or ALGOL60. It turns out 
that appropriate display register permutations can be determined at compile 
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time what does not diminish run time efficiency. Section 6 shows the essential 
ideas. 

Remark concerning Java: Both methods in sections 4 and 5 eliminate pre- 
fixing and so reduce semantics definition to programs without inheritances, but 
with nestings. Java’s method removes class nestings and reduces semantics defi- 
nition to flat programs with toplevel inheritances only. The connections between 
the methods are to be clarified [SaW02]. 

6 Implementation of MiniLOGLAN 

6.1 Problem Review 

Design of an efficient implementation for LOGLAN with many level prefixing 
and pure static scope semantics is a problem more severe than for ALGOL60 or 
Simula67. The idea to start with is Dijkstra’s [DiJ60], namely to enter activa- 
tion records or incarnations in a run time stack when modules are activated and 
to use compile time determinable display (index) registers and ojfsets (relative 
addresses) for fast access to contents of variable and parameter places. As for 
Simula67, incarnations of modules in one prefix chain shall be grouped as one so 
called object instance or object in one activation record and no display register 
reloadings shall be needed as long as a computation is running through main 
parts of modules in a prefix chain. As an illustration look at the run time stack 
content (pure static scoping) of program tti in appendix E (with its environmen- 
tal and prefix structure in Section 3) just before class G is terminating. 

In Simula67 as in ALGOL60 or Pascal it is correct to associate every module 
M of level vm straight forwardly with a list of display registers numbered from 
1 to Vm, to associate every applied occurrence of a variable with a display 
register numbered £^nd, at run time, to load register vm to register 1 

with pointers by going down the static pointers chain of the activated module 
M. 

But this proceeding does no longer work out for many level prefixing. Krog- 
dahl [Kro79] discusses this problem; he recommends to look for compile time 
optimization procedures to minimize display register loadings and reloadings at 
run time. 

The first implementation of LOGLAN-77/82 used a 1- 1-association of mod- 
ules and display registers in order to avoid reloadings as long as a computation 
is residing in a prefix chain of a module. A total of 6 registers were needed for 
7Ti . But that implementation did not fit static scoping, output of tti showed 

2.0, 2.0, 2.0 instead of the expected 2.0, 2.0, 3.0 

That phenomenon was observed 1983. So the implemented semantics was called 
quasi static scope. 

The articles [KKSL84, KLKW85, KKLSW87] and Krause’s dissertation 
[Kra86] prove that appropriate compile time determined display register permu- 
tations get along with a number v^ax of display registers which is the maximum 
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module nesting level in a program. This works successfully for pure static scop- 
ing and many level prefixing, no reloadings inside prefix chains take place. Since 
ALGOL60- or Simula67-like programs already require this number i>rnax we may 
state: The compile time determined display register permutations are a solution 
of Krogdahl’s optimization problem. The fact that MiniLOGLAN is only a re- 
stricted LOGLAN and does not yet allow object reference storing nor remote 
(indirect) identifier access nor virtual procedures is no point against display 
register permutation. The missing language constructs can be added without 
problems, they do not overthrow the implementation idea. 

Our program examples tti and tt 2 in appendices B and G show the following 
permuted display register lists associated to modules. 



7Ti: 




M 


1 


7T2: 


M 

t 




1 


1,2 


LI 





1,2 




A 




1,2 




t 








A 






1,3,2 


L3 




1,2,3 


1,2,3 


BA 


-N 


1,3,2 














t 








^ " 














C 


''' 1, 2,4.3 








C 


1, 4,2,3 



We see very clearly that many level prefixing induces non-trivial permuta- 
tions. 

Display register permutations for efficient implementation of MiniLOGLAN- 
programs (and LOGLAN-programs in general) are a result of viewing programs 
as L-algebras. 

Static scoping is enabling that not only the set of modules in a wellformed 
program tt may be seen as an L-algebra A4. This holds also for sets of the 
module instances in expanded programs tt generated by successive prefix elim- 
inations, class instantiations and copy rule applications, tt’s L-algebra Af is a 
so called implementation of tt’s L-algebra M with a characteristic embedding 
homomorphism h from M into M: The pref-trees in A4 are linear paths (object 
instances), li M = h{M), then any path of pref- and encZ-applications starting 
from M can be lifted to an analogous path starting from M (the other way round 
is clear by the notion homomorphism). Similarly for complement diagrams: If 
M = h(M), M' = h(M), M” = h(M"), m' = pref*(M),M” = end*{M') 
then comp{M, M' , M") = h{comp{M, m' , m"). 

We define display register association and present a correctness proof basing 
on L-algebras and their implementations. 

6.2 Association of Lists of Display Registers to Modules and Its 
Correctness 

At compile time every module M of level vm > 1 of program tt shall be associated 
with Vm display registers numbered 



dM(l), • ■ • , dM(j^M) 
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with 1 < < vm for /X = 1, , vm- So (1m is a permutation of the numbers 

1, . . . , vm- Main purpose of M’s display registers is to have fast access to a local 
or global variable or parameter of M with its defining occurrence in its 
declaring module ^ M' which is in the prefix chain of the vertex module oi 

But our wishes go further. Display register association shall be so intelligent 
that no display register reloadings are necessary as long as a computation is 
running in the main parts of M’s prefix chain 

M = pref'^{M) > pref^{M) > • • • > pref”^~^{M) 

where pref^{M) is undefined and > 1 is the length of M’s prefix chain. 
This requires a uniformity condition to be fulfilled which bases on the notion of 
a complement modules chain. 

Module M has its enclosing modules chain 

M = M^^ = endP{M) — > = end}{M) ^ . . . 

— > Ml = encl''^~^{M) = tt 

Let M' = pref\M),0 < / < — 1 , be any module in the prefix chain of 

module M and let 



M' = Ml ^ Ml 1 ^ . . . ^ Ml = TT 
be M' ’s enclosing modules. This chain has a complement modules chain 

^ ^ i i Ma(1) = TT 

of length vm' inside M’s enclosing modules chain such that 

vm = A(ixm') < ^{vm' — 1) < ■ • • < A(l) = 1 . 

A(/i') is the level of the complement module Mx(^>) of M, M', Ml> for 

1 < p' < vm' ■ The decisive uniformity condition to be fulfilled is: 

Condition 6.2.1: 

dM(A(/x')) = dM'(At') resp. \{p') = d]^^ o dn'iiJ-') 
for all p' with 1 < p' < I'm' ■ 

Is such an association dM of lists of display register numbers to modules M 
possible? Yes. We define dM by induction over the lexicographical ordering of 
couples {I'M, Im) of levels vm and prefix chain lengths Im ■ 

Induction beginning {vm, Im) = (1, 1) : 
dM(l) := 1 

is the only choice possible. 

Induction step {vm, Im) yf (1, 1), first case Im = 1 '■ Then vm > 1 and there is 
an M' with 
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M ^ M' , 

vm' = vm — 1 , and {vm< , Im') precedes {vm', Im) lexicographically. So <1m' may 
be assumed to be defined. 

, / X fdM'(/^) for /i= 

UM(tJ-) '■= S r 

[vm for /i = VM ■ 

Second case Im > ^ ■ Then there is an M' with 
M > M' , 

vm' < Vm , Im' = W — 1 , and {vm',Im') precedes (vmJm) lexicographically. 
So d,M' may be assumed to be defined. 



' dM'ifJ-') if and are in the enclosing modules chains 

of M and M' and = comp{M, M' , = X{p') 



dMin) ■= < 



vm' + 5 if is in the enclosing modules chain of M, but 
outside the complement modules chain of M ' , and 
is the (5-largest module of that kind, 

I < 5 < Vm — vm' 



In case we have same level prefixing as in Simula67 then case dM{^d) = vm> +<5 
never applies and all c^m are identical mappings. Due to definition of the notion 
complement module and due to composition theorem 3.3 the following holds: 



Lemma 6.2.2 : Our defined display register permutations dM satisfy the unifor- 
mity condition 6.2.1. 



For a correctness proof of our definition of dM we have to explain beforehand 
what is to be proved: In practice the contents of display registers Dr[dM{fJ')] 
are linkage addresses of object instances (prefix chains of module incarnations). 
Since we would like to base our proof on L-algebra implementation 

h:M — >M 

we take object instances themselves, i.e. maximal prefix paths in A4, as contents 
of display registers. Every module instance M e is an element of exactly one 
maximal prefix path, these paths define a partition of M. and an equivalence 
relation « in AI. 

Let module M e A4 he activated at runtime by instance M e M. with h{M) = 
M. So the runtime system loads display register Dr\dM{yM)] with M’s maximal 
prefix chain 

M = pref{M) > . . . > pref^~^{M) , Ijj=Im , 

which is the equivalence class [M]~ of M . Every display register Dr[dM{^d)\, 
\ < pL < Vm , is loaded with [M^]~ where M ^ is that instance of level p in the 
enclosing chain 
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This same loading is done when at run time after an interruption the computa- 
tion is returning to or is resumed by object instance [M]~ . 

* 

Now let M' be in the prefix chain of M , i.e. M > M' and correspond- 
ingly M > M with h{M ) = M' . Let be a local or global variable 

or parameter occurrence in the main part of M' with its defining occurrence 
in its declaring module ^ M” which is in the prefix chain of the vertex module 
^M' of To have a fast access to the storage place of resp. we cou- 
ple (in fact, the compiler generated target code couples) the applied occurrence 
with display register Dr[dM'{^J■')] where is the level of the vertex module 
= M'^, in M'’s enclosing chain 

M' = ^ ^ M'^, ^ ^ M[ = TT , VM' < VM- 

Our claim is: As long as computation is running in object instance [M]~ dis- 
play register Dr[dM'{^J-')\ is already correctly loaded at object activation resp. 
resumption time. Bare transitions between module instances inside \M]~ need 
no reloading. This means more precisely: Consider the enclosing chain 

m' = ^ ...^ m' , ^ ...^ m[=tt , =VM>, 

for M . M' ’s display registers are said to be correctly loaded if 

e Dr[dM'{i^')], e Dr[dM'{fJ-')], ■■■, e Dr[dM'{l)] ■ 

We have a diagram 



h h 




So comp{M , Al' , m'^,) is Mx(^') which is e Hr[dM(A(/r'))] by explicit 
loading and e Dr[dM'{d')] due to uniformity guaranteed by lemma 6.2.2. So 
M € DrldM'id')] because display registers of M are loaded with maximal pre- 
fix chains in A4 and m'^, with = M'^, = is a prefix of We 

see: M'’s display registers are correctly loaded in the sense above. 

Why does this guarantee the right access to ®^'’s storage place? Remem- 
ber that the declaring module ^ AI" is in the prefix chain of vertex module 
= AI'^, . So the defining occurrence has a storage place in a correspond- 
ing instance m” with h{Al”) = ^ M" which is in the prefix chain of . So 
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m” e DrldM'ilJ-')] , and this demonstrates the coupling of applied occurrence 
with display register Dr\dM'{d')] is correct. This proves the correctness theorem: 

Theorem 6.2.3: The display register associations dM are correct. A module 
needs only I'm registers. The associations are efficient in the sense that no reload- 
ings are needed as long as a computation does not leave a prefix chain. 

Important remark: It is well possible that different applied occurrences of the 
same variable in one prefix chain must be coupled to different display registers. 
So it is with x in class B and x in class C of program tti which are coupled with 
display register 2 resp. 4. See appendix D and E. 

7 Conclusion 

We would like this partly historical essay to be viewed as our high appreciation 
of O.-J. Dahl’s and K. Nygaard’s software engineering research on object orien- 
tation and its persistent combination with static binding which ALGOL60 has 
introduced in programming theory and practice and which has been known ear- 
lier in predicate logic and A-calculus. Influential publications have unvoluntarily 
brought dynamic binding to the attention of programming practice. Dynamic 
binding became especially popular in object oriented programming although the 
inventors had a different view. 

The Warsaw algorithmic logic and programming research group around A. 
Kreczmar and A.Salwicki has worked on object orientation in quite the same 
sense as the inventors. The Warsaw group defined and implemented several Sim- 
ula 67-extensions, named LOGLAN77/82/88. One new language feature which 
Simula 67 excluded was many level (skew) prefixing. It was interesting to find 
out that the first many level prefixing implementation had deficiencies w.r.t. 
static binding. It proved to be a challenge to find a good efficient solution and a 
convincing justification. The problems that have come up were not foreseen in 
1967 [DahOlb]. 

Our view of many level prefixed programs as classical ALGOL-programs with 
appropriate nested procedures and parameter transmissions have guided us to 
implement many level prefixing with the same display registers quantity and 
run time efficiency as same level prefixing, e.g. Simula 67. A right notion of 
complement module has given us the idea of display register permutation. 

In order to prove the idea correct we view both original programs and their ex- 
pansions and run time stack contents more abstractly as L-algebras. Expansions 
and stack contents, so called implementing L-algebras, are homomorphically em- 
bedded in the original programs. This L-algebraic view, enabled by static scop- 
ing, is sufficiently abstract such that typical object oriented language constructs 
like remote (indirect) addressing, object reference storing or virtual procedures 
are in concordance with the display register permutation idea. 

I would like to thank my colleagues Grazyna Mirkowska, E. Borger, O.-J. 
Dahl, W. Goerigk, G.A.R. Hoare and A. Salwicki very heartily for many discus- 
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sions around object orientation and static binding. Thanks also to an anonymous 
reviewer for his good suggestions. My conversations with O.-J. Dahl around the 
sd&m software pioneers conference at Bonn [DahOla] have especially encour- 
aged me to lecture anew on consistency of object inheritance and static bind- 
ing [LanOl]. I am grateful to the editors who have invited me to contribute to 
the Festschrift in honour of our dear respected colleagues Ole-Johan Dahl and 
Kristen Nygaard. I thank Annemarie Langmaack and Moritz Zahorsky for type- 
setting the manuscript. Ole-Johan was a wonderful pianist; he together with 
Annemarie as a violinist enjoyed the participants of many informatics confer- 
ences since 1972. 
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Appendix A : A contextfree-like grammar for MiniLOGLAN 



The grammar is an adapted extraction from [KSW88]. “Contextfree-like” , as op- 
posed to “contextfree” , means that the productions are contextfree, but there 
may be infinitely many productions, terminal and non-terminal symbols. Termi- 
nal symbols or lexical entities are identifiers, literals, keywords and delimiters. 
Non-terminal symbols are written in angle brackets < > . Axiom is <program>. 
The production system is not complete. The reader is urged to add missing 
productions appropriately. 



< program > 

< block > 

< body > 

< deck > 

< var. deck > 

< class deck > 

< proc. deck > 

< var. spec. > 

< var. type def. > 

< form. par. spec. > 

< type name > 

< stm. > 



< act. par. > 



< block > 

[< block idf. >:][inh < class idf. >]block < body > 

[< block idf. >] 

< deck >*< stm. >* end 

< var. deck > 

I < class deck > 

I < proc. deck > 
var < var. spec. > 

unit < class idf. >: [inh < class idf. >] class < body > 
[< class idf. >] 

unit < proc. idf. >: [inh < class idf. >]proc 

(< form. par. spec. >*) < body > [< proc. idf. >] 

< var. idf. >:< var. type def. > 

< prim, type idf. > 

I < class idf. > 

< form. par. idf. >:< par. transm. mode > 

{< type name > | < type >} 

< prim, type idf. > 

I < class idf. > 

I < proc. idf. > 

< empty stm. > 

I < assignm. stm. > 

I call < proc. idf. > (< act. par. >*) 

I new < class idf. > 

I inner 
I < block > 

I < compound stm. > like loop, conditional, 

case statement 

< var. idf. > 

I < proc. idf. > 

I < class idf. > 

I < form. par. idf. > 



Defining identifier occurrences are indicated by immediately following 
colons : , all other identifier occurrences are applied ones. Conditions for well- 
formedness (correct static semantics) of programs are formulated in Section 3. 
In order to handle prefix elimination and program semantics by copy rule 
applications and program expansions it is advisable to have an extra production 



< stm.> 



gbegin <body> 
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which introduces so called generated statements or instanees of modules. For 
later treatment of indirect (remote) identifier access productions like 



<var. type def.> ::= < class idf.> . <var. type def.> 
<type name> <class idf.> . <type name> 

<var. name> ;:= <var idf.> 

I <class idf.> . <var idf.> 



ought to be added. For object generation (class instantiation) and storing object 
references a special assignment statement is needed 



<assignm. stm.> :;= <var. name> ;= new<class idf.>. 



Appendix B: 

Program example tti 

M: block 

var x: real; 
unit A; class 
var x: real; 
x:=3; 
inner 
end A; 

LI: inh A block 
var y: real; 
unit B: class 

x:=y; print(x); 
inner 
end B; 
y:=2; 

L2: new B; 

L3: inh A block 
var y: real; 
nnit C: inh B class 
y:=x; print(y); 
inner 
end C; 
y:=4; 

L4; new C 
end L3 
end LI 
end M 

L2 and L4 are redundant 
statement labels. 



Appendix C: 

Program example tt 2 with recursive 
prefixing. The original prefix elimi- 
nation process is infinite. 

M: block 

var y: real; 
nnit A: class 
var x: real; 
nnit B: class 
x:=y; 
inner 
end B; 

LI: new B; 
inner; 

nnit N : inh A block 
var y-. real; 
nnit C : inh B class 
y:=x; 
inner 
end C; 

L2: new C; 
end N 
end A; 

L3: new A 
end M 

LI, L2, L3 are redundant statement 
labels. 
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Appendix D: Elimination of all prefixes in program tti yields tt" : 



M: block 

var X-. real; 

(* class A deleted *) 

LI: block 

var x: real; 

X := 3; 
gbegin 
var y: real; 

(* class B deleted *) 

y := 2; 

L2: block 

X := y; print(x); (* see comment 1 *) 
gbegin 
end 
end L2; 

L3: block 

var x'\ real; 
x' := 3; 
gbegin 
var y\ real; 

(* class C deleted *) 



1/ := 4 ; 

L4: block 

x := y ; print(x); (* see comments 2 and 3 *) 

gbegin 

y ■.= x' ■ print(y); 

gbegin 
end 
end 
end L4 
end 
end L3 
end 
end LI 
end M 



Comment 1: The first output is 2.0, no matter whether static scoping, dynamic 
scoping or quasi static scoping (i.e. dynamic scoping starting from a distinguished 
program, renaming of x in M to a: , of y in L3 to y ) , is done. 

Comment 2: y is the first variable access where static scoping violates dynamic 
scoping because y does not access the most recent defining occurrence y. The 
second output is 2.0 whereas dynamic scoping would yield 4.0. Quasi static 
scoping would still behave as static scoping and so yield the same second output 

2.0 . 
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Comment 3: x is the first variable access where static scoping violates quasi 
static scoping because x does not access the most recent defining occurrence 
x' . The third output is 3.0 whereas quasi static scoping would yield again 
2.0. Here static scoping deviates from Dijkstra’s most-recent-behaviour in 
the same way as in the short ALGOLOO-program examples of [GHL67] and 
[Kan74]. When class C, prefixed by B, is initialized then B does not store 
value 2.0 in that place reserved for B’s global variable x within the most recent 
incarnation of class A, but within the older one. Observe that this deviation 
from most-recent-behaviour is generated by block enterings, class initializations 
and many level prefixing without any help of nested procedures with formal 
procedure identifiers as parameters. 



Appendix E : Runtime stack of program tti just before class initalization 
new G terminates. 

static 

pointers 

chain 



linkage block M 
fixed storage M 



linkage block LI 
older fixed storage A 
fixed storage LI 



linkage block L3 

most recent fixed storage A 

fixed storage L3 



linkage class C 
fixed storage B 
fixed storage C 

beginning free storage: C’s list 

12 4 3 

of display registers 
and their pointings 
into the static 





pointers chain 



Both the block and class instances in the expanded program tt" and the 
incarnations in the run time stack above are L-algebras. Specific homomorphisms 
h from them into tti ’s L-algebra make the L-algebras so called implementations 
of TTi’s L-algebra. The static pointers of the object instances in the run time 
stack allow to determine the enclosing function end of all incarnations implicitly. 
Observe: The applied occurrences of one and the same global variable x in class 
B and class G (the prefix chain of G) are coupled with different display registers 
2 and 4. 
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Abstract. A new library for event-driven design, defining a general and 
extendible scheme yet easy to learn and use on both the publisher and subscriber 
sides, provides an opportunity to analyze such other approaches as the “Observer 
Pattern”, the event-delegate mechanism of .NET and its “Web Forms”, then to 
draw some general software engineering lessons. 



1 Overview 



Event-driven software design avoids any direct connection, in a system’s architecture, 
between the unit in charge of executing an operation and those in charge of deciding 
when to execute it. 

Event-driven techniques have gained growing usage because of their flexibility. 
They are particularly common for Graphical User Interface applications, where the 
operations come from an application layer and the decision to execute them comes from 
a GUI layer in response to events caused by human users. An event-driven scheme can 
shield the design of the application layer from concerns related to the user interface. 
Many application areas other than GUI design have used these ideas. 

Closely related techniques have been proposed under such names as Publish- 
Subscribe and Observer Pattern. 

This article describes the Event Library, a reusable component solution of broad 
applicability, covering all these variants. Intended to be easy to learn, the library 
consists in its basic form of one class with two features, one for the production of events 
and one for their consumption. 

The discussion will compare this solution to the Observer Pattern and mechanisms 
recently introduced by .NET. It will expand on this analysis to examine more general 
issues of software engineering, including the role of abstraction, the transition from 
design patterns to reusable components, the concern for simplicity, and the contribution 
of object technology. 

Section 2 quickly presents the essentials of the Event Library. Section 3 explains 
event-driven design and what makes it attractive. Sections 4, 5 and 6 analyze other 
solutions: the Observer Pattern, the .NET event handling mechanism, the Web Forms 
library of ASP.NET. Section 7 gives the remaining details of the Event Library. 
Section 8 examines the software engineering issues that led to this work and draws 
general conclusions. 
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2 Event Library Essentials 

The Event Library consists at its core of one class, EVENT_TYPE with a feature publish 
for publishers and a feature subscribe for subscribers. The library is written in Eiffel; so 
are the usage examples in this section. 

First the subscriber side. Assume you want to ensure that any future mouse click 
will cause execution of a certain procedure of your application 



yourjprocedure (a, b: INTEGER) 



passing to it the mouse coordinates as values for a and b. To obtain this effect, simply 
subscribe the desired procedure to the event type mouse click: 



mousejcHck. subscribe (agent yourjprocedure) 



IM 



The argument to subscribe is an “agent” expression; an agent in Eiffel is an object 
representing a routine, here yourjprocedure. 

In most cases this is all one needs to know on the subscriber side, for example to 
produce a graphical application using a GUI library. An advantage of the scheme is that 
it lets you start from an existing system and add an event-driven scheme such as a GUI 
without writing any connecting code. You’ll just reuse the existing routines directly, 
linking them to event types through agent expressions as above. This extends to routines 
with extra arguments: assuming 



otherjprocedure (text: STRING', a, b: INTEGER', date: DATE) 



you can still subscribe the procedure without any “glue code” through 



mousejcHck. subscribe (agent other procedure ("TEXT", ?, ?, Today) 121 



where the question marks indicate the values to be filled in by the event. (The agent in 
form /!/ can be written more explicitly as agent yourjprocedure (?, ?).) 

So much for subscribers. The basic scheme for publishers is also straightforward. 
To trigger a mouse click event, all the GUI library will do is 



mouse_click. publish {[xjposition, yjposition]) 



131 



It is also the publisher’s responsibility to declare mouse_click and create the 
corresponding object. It can take care of both through 



mouse_click: EVENT_TYPE [TUPLE [INTEGER, INTEGER]] is 

once 

create Result 

end /4/ 
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Class EVENT_TYPE is generic; the parameter TUPLE [INTEGER, INTEGER] indicates 
that a mouse click produces event data consisting of two integers, representing the 
mouse coordinates, collected into a two-element “tuple”. 



Since mouse_cUck just represents an ordinary object — an instance of class 
EVENT_TYPE — the instruction that creates it could appear anywhere. One possibility, 
as shown, is to put it in a “once function” defining mousejcUck. A once function is 
executed the first time it’s called, whenever that is, the same result being returned by 
every subsequent call. This language mechanism addresses the issue of providing 
initialization operations without breaking the decentralized architecture of well- 
designed 0-0 systems. Here it creates the mouse click object when first needed, and 
retains it for the rest of the execution. 

The scheme as described covers global events: the subscriber call III subscribes 
your_procedure to any mouse click anywhere. Instead we may want to let subscribers 
select events in a given graphical element such as a button. We simply turn mouse click 
into a feature of class BUTTON, so that subscriber calls will be 



your_button. mouse_cllck. subscribe (agent your procedure) 151 



perhaps clearer as your_button_cllck. subscribe (agent your_procedure), retaining the 
original form III with your_button_click set to your_button.mouse_click. 



What we have just seen defines, for the majority of applications, the user’s manual 
of the Event Library: 

• On the publisher side, declare and create the event type object; trigger a 
corresponding event, when desired, by calling publish. 

• On the subscriber side, call subscribe with an agent for the desired routine. 

Only one class is involved, EVENT_TYPE; there is no need to define specific classes 
for each event type (mouse click, mouse movement etc.) as, for example, in the .NET 
model studied below — although you can do so if you wish by introducing descendants 
of EVENT_TYPE that specialize the event data. There is also no need for the publishers 
or the subscribers to inherit from any particular classes, such as the abstract classes 
SUBJECT and OBSERVER of the Observer Pattern, also studied below. 



Section 7 will describe some of the more specialized features of the library. As is 
often the case when the basic design of a library uses a small number of abstractions 
tailored to the problem, it is possible to add special-purpose facilities without disturbing 
users who need only the basics. 

To understand the rationale behind this design, we will now step back to examine the 
general issues of event-driven computation, and some previously proposed solutions. 
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3 Event-Driven Design 

Event-driven design offers interesting architectural solutions when execution must 
respond to events whose order is hard to predict in the program text. 

Putting the User in Control 

GUI and WUl (Web User Interfaces) provide the most immediately visible illustration 
of why an event-driven scheme may be useful. 

Consider this piece of WUl built with ASP.NET (the Web library for .NET): 

File Edit View Favorites Tools Help 

Back ’ ! y Search Favorites Media 

: Address http: //guy ana. ise/instant. net/display _time.aspx 



What time is it? 



23l 14:00.0974384 



Figure 1: A Web User Interface under ASP.NET 



The interface that we show to our user includes a text field and a button. There might 
be many more such “controls” (the Windows term for graphical elements, called 
“widgets” in the X Window system). We expect that the user will perform some input 
action, and we want to process it appropriately in our program. The action might be 
typing characters into the text field, clicking the button, or any other, such as menu 
selection, using controls not shown above. 

But which of these will happen first? Indeed, will any happen at all? 

We don’t know. 

In the early days, the problem didn’t exist. Programs would just read user input, 
using for example a loop to consume successive lines, as in 



from 

readjine 
count := 0 

until 

lastjine.is_empty 

loop 

count := count + 1 

— Store lastjine at position count in Result: 
Result, put {lastjine, count) 
readjine 

end 



This was good enough when we had a single sequential input medium and the program 
was in charge of deciding when, where and how to enjoin the user to enter some input, 
for example on a teletype console. 
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With current input techniques, a user sitting at a graphics workstation is free at 
any time to go to the text field, the button or any other control. He, not the program, 
is in control. 

To support such modes of interaction, event-driven programming replaces a control 
structure by a data structure. A control structure means that the program decides when 
to execute things. Instead we want to let the user decide what to do next. We’ll call these 
user decisions events. The system will use a data structure — let’s call it the event- 
action table — to record in advance the actions that it has to execute when events of 
specific types occur. After that it relies on the event handling machinery to watch for 
events of recognized types and, when detecting one of them, trigger the corresponding 
action as found in the event-action table. 



A role remains for control structures: each operation, while it executes, defines the scheduling of 
its own operations, using a control structure that can be arbitrarily complex. But when the operation 
terminates the event-driven scheme takes over again. 



Overall, it’s a major change. The program has relinquished direct control of global 
execution scheduling to a generic table-driven mechanism. For best results that 
mechanism should be a library, for example a GUI or WUI library, or — more generic 
yet — the Event Library, not tied to any specific application area. 

This yields a clear division of tasks between such a general-purpose library and any 
particular application. The application is in charge of recording event-action 
associations; when the true show begins, the library is in charge of catching and 
processing events. 

Application authors have their say, since what gets executed in the end are the 
actions — taken from the program — that they have planted in the table. But they do 
not directly control the scheduling of steps. 

The library owns the event-action table, so that application programmers should not 
need to know anything about its implementation. With the Event Library they simply 
record event-action associations, through calls to subscribe; the library takes care of 
maintaining these associations in the appropriate data structure. We’ll see that in some 
other frameworks, such as .NET, programmers work at a lower level of abstraction, 
closer to the internal representation of the event-action table. 
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Publishers and Subscribers 

The overall scheme of programming in an event-driven style is this: 

1 • Some part of the system is able to trigger events. We call it a publisher. 

2 • Some part of the system wants to react to these events. We call it a subscriber. 

(“Observer” would also do, as in the “Observer Pattern”, where the publisher is 
called a “subject”.) 

3 • The subscriber specifies actions that it wants to execute in connection with events 

of specified types. We’ll say that the subscriber registers an action for an event 
type. The effect of registration is to record an association between an event type and 
a subscriber into the event-action table. Registrations usually happen during 
initialization, but subscribers can continue to register, or de-register, at any time of 
the execution; that’s one of the advantages of using a table-driven scheme, since the 
table can be modified at any time. 

4 • At any time during execution proper, after initialization, the publisher can trigger 

an event. This will cause execution of the routines that any registered subscribers 
have associated with the event’s type. 

For this discussion we must be careful about distinguishing between events and event types. The 
notion of mouse click is an event type; a user clicking his mouse will cause an event. Although the 
data structure is called the evewt-action table for brevity, its definition clearly specified that it 
records information about event types. Publishers, on the other hand, trigger events, each of a 
certain type. 



Healthy skepticism should lead us to ask why we need all this. Instead of an indirect 
relationship through an event-action table, couldn’t we just skip step 3 and let, in step 
4, the subscriber call the publisher, or conversely? 

A subscriber can indeed call its publishers directly through a generalization of the 
earlier sequential reading scheme: it will listen to events of several possible types rather 
than just one, pick up the first one that happens, select the appropriate action, and repeat. 
This has, however, two limitations. One is that you need to put the subscriber in charge 
of the application’s control structure; that is not always appropriate. Another, more 
serious, is that it is not easy with this scheme to ensure that events raised by a publisher 
trigger actions in several subscribers. 

Alternatively, the publisher could call the subscriber’s routine directly 



my subscriber. routine (my_arguments) 



using the standard object-oriented call mechanism. This works as long as the whole 
scheme is static: the publishers know their subscribers, and this information is defined 
once and for all so that publishers’ code can include calls such as the above for each 
subscriber to each event type. 

The limitations of both solutions indicate where event-driven programming 
becomes interesting. We may picture the general situation as one of those quantum 
physics experiments that bombard, with electrons or other projectiles, some screen with 
a little hole: 
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PUBLISHERS SUBSCRIBERS 

trigger events handle events 




Figure 2: Triggering and handling events 

The event-driven scheme decouples the subscribers from the publishers and may be 

attractive if one or more of the following conditions hold: 

• Publishers can 't be required to know who the subscribers are: they trigger events, 
but do not know who is going to process those events. This is typically the case if 
the publisher is a GUI or WUI library: the routines of the library know how to detect 
a user event such as a mouse click, but they should not have to know about any 
particular application that reacts to these events, or how it reacts. To an application, 
a button click may signal a request to start a compilation, run the payroll, or shut 
down the factory. To the GUI library, a click is just a click. 

• Subscribers may register and deregister while the application is running: this 
generalizes the previous case by making the set of subscribers not only unknown to 
publishers but also variable during execution. 

• Any event triggered by one publisher may be consumed by several subscribers. For 
example the event is the change of a certain value, say a temperature in a factory 
control system; then the change must be reflected in many different places that 
“observe” it, for example an alphanumeric display, a graphical display, and a 
database that records all historical values. Without an event mechanism the 
publisher would have to call routines in every one of these subscribers, causing too 
much coupling between different parts of the system. This would mean, in fact, that 
the publisher must know about all its subscribers, so this case also implies the first 
one. 

• The subscribers shouldn 't need to know about the publishers: this is less commonly 
required, but leads to the same conclusions. 

In all such cases the event-driven style allows you to build a more flexible architecture 

by keeping publishers and subscribers at bay. 
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There is a downside: if you are trying to follow the exact sequence of run-time 
operations — for example when debugging an application — you may find the task 
harder, precisely because of the indirection. A plain call x. f ( ... ) tells you exactly what 
happens: after the preceding instruction, control transfers to f, until fs execution 
terminates, and then comes back to the instruction following the call. With an 
instruction that triggers an event, all you know is that some subscribers may have 
registered some routines to handle events of that kind, and if so they will execute these 
routines. But you don’t immediately know who they are; indeed they may vary from 
execution to execution. So it is more delicate to track what’s going on. One should 
weigh this objection — which some authors have proposed to address by replacing 
event-driven design with techniques inspired by parallel programming [18] — before 
deciding to embark on an event-driven architecture. 

Controls 

In cases such as GUI and WUI programming, the event-action table will generally 
contain not mere pairs — actions coupled with event types — but triples: we don’t just 
specify “for events of this type, execute that action”, but “for events of this type 
occurring in this control, execute that action”, as in: 

• “If the user dicks the EXIT button, exit the application” . 

• “If the mouse enters this window, change the border color to red”. 

• “If this sensor reports a temperature above 40° C, ring the alarm”. 

In the first case the control is a button and the event type is “mouse click”; in the second, 
they are a window and “mouse enter”; in the third, a temperature sensor and a 
measurement report. 

A “control” is usually just a user interface element. As the last example indicates, 
the concept also applies outside of the UI world. 

A common library interface to let subscribers deposit triples into the event-action 
table (we’ll continue to call it that way) uses calls of the conceptual form 



record_association {some_control, some_event_type, some_action) 161 



and leaves the rest to the underlying GUI or WUI machinery. That’s the essence of 
event-driven programming as supported by many modem graphics toolkits, from 
Smalltalk to EiffelVision to the Windows graphical API and the Web Forms of .NET. 
The most common variant is actually 



add_association {somejcontrol, some_event_type, some_action) 



which adds some_action to the actions associated with some_event_type and 
somejcontrol, so that you can specify executing several actions for a given event- 
control pair. We’ll retain the first form 161 since it corresponds to the most frequent need; 
it includes the second one as a special case if we assume a provision for composite 
actions. 

The Event Library seemed at first not to support controls since the basic mechanism 
mouse_click, subscribe (...) /!/ did not make them explicit; but we saw that it’s just a matter of 
making an event type belong to a control object, then use your_button, mouse_click, subscribe (...) 

/5/, which directly provides the general scheme 161. 
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Actions as Objects 



In a classical 0-0 language, we have a problem. Even though we don’t need to 
manipulate the event-action table directly, we know it will exist somewhere, managed 
by a graphical library, and that it’s a data structure — a structure made of objects, or 
(more realistically) references to objects. In each entry we expect to find a triple 
containing references to: 

• One control. 

• One event type. 

• One action — or, as a result of the last observation, one list of actions. 

Are these things objects? Controls, definitely. Any graphical 0-0 library provides 
classes such as WINDOW and BUTTON whose instances are objects representing 
controls — windows, buttons and so on. Event types too can be defined as objects in an 
0-0 language; we saw how the Event Library does it. But what about actions? 

Actions are given by our program’s code. In an 0-0 program, the natural unit for 
an action is a routine of a class. But a routine is not an object. 

This won’t be too much of a concern for a C-l-l- programmer, who may just use a 
function pointer, an integer denoting the address where a routine’s code is stored, 
providing a way to execute the routine. But that’s not type-safe, since one can do too 
many other things with the pointer. As a consequence, 0-0 languages intent on 
providing the benefits of static typing do not provide function pointers. 

The notion of agent used in the Event Library is an object-oriented mechanism that 
addresses the issue within the constraints of type checking. An Eiffel agent is an object 
that represents a routine ready to be called. 



Some of its operands (target and arguments) can be fixed, or closed, at the time the agent is defined; 
the others, called open operands and expressed — when needed — as question marks ? in earlier 
examples, must be provided at the time of each call. In agent some_routine all arguments are open; in 
agent some_routine {1, 7, 7, "SOME TEXT') the first and last arguments are closed, the others open. 
You can also make the target open, as in agent {TARGET_TYPE\,some_routine {1, 7, 7, "SOME TEXT'). 



Some languages provide comparable mechanisms under the name “block” or “closure”. 
The “delegates” of .NET and C# are a limited form of agent where arguments are 
always open and the target is always closed. 

Java doesn’t have such notion, meaning that to represent an action as object you 
have to create a little class that includes the corresponding routine. The availability of 
“nested classes” limits the amount of code that must be written for such classes, but the 
solution lacks extendibility and scalability. 
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Avoiding Glue 

When building an event-driven application, you will need at some stage to connect the 
subscribers with the publishers. One of the guiding concerns — reflected in the design 
of the Event Library — must be to keep such connections as light as possible. 

This goal is particularly relevant to the common case of restructuring an existing 
application to give it an event-driven architecture. The application may provide many 
functions, perhaps developed over a long period and embodying a sophisticated 
“business model” for a certain domain. The purpose of going event-driven might be to 
make these functions available through a graphical or Web interface, taking advantage 
of an event-driven GUI or WUI library. In this case both the business model and the 
library predate the new architecture. 



Common names for the three parts appearing on the figure follow from the Smalltalk 
“MVC” scheme that inspired many event-driven GUI designs: Model for the existing 
application logic. View for the user interface, and Controller for the connection between 
the two. 

With such terminology the above goal is easily stated: we seek to get rid of the 
Controller part, or reduce it to the conceptually inevitable minimum. 

The Event Library offers two complementary styles to achieve this. In the first 
style, we let the application consume events by becoming a subscriber through calls of 
the form seen earlier 



some_event_type. subscribe (agent some_routine) m 



explicitly making the consumer application event-driven. 

In many cases this is appropriate. But what if you want to reuse both the event 
producer and the event consumer (the application) exactly as they are? The Event 
Library and the agent mechanism allow this too. You’ll leave both the producer and the 
consuming application alone, connecting application routines to producer events 
through a simple intermediary. Just add an explicit target to the agent expression: 
instead of agent somejroutine as used above, which denotes the routine ready to be 
applied to the current object, you may select any other object as target of the future call: 



some_event_type. subscribe (agent other_object. somejroutine) 181 



Event producer 
(e.g. GUI) 




^ “Glue code” 




Figure 3: Connecting publishers and subscribers 
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By using either form, you can select the style that you prefer: 



Event producer 



Direct subscription 
(Scheme 111) 



V 




Business model 



Connection 

object 

(Scheme /8/) 



Figure 4: Two connection styles 

Either may be appropriate depending on the context: 

• Scheme 111 adds event-driven scheduling to an existing application by plugging in 
routines of that application directly. 

• Scheme /8/ lets you reuse both pre-existing event producers (publishers) and pre- 
existing event consumers (subscribers), unchanged. By definition, you’ll need 
some glue code then. Scheme /8/ reduces it to the minimum possible: calls to 
subscribe using agents with explicit targets. One of the benefits of this style is that 
it lets you provide several interfaces to a given application, even within a single 
program. 

To reduce the need for glue code even further, you may take advantage of the agent 
mechanism’s support for combining closed and open arguments. Assume that an 
existing meteorological application includes a routine 



show_rainfall (x, y: INTEGER', start, end : DATE)'. REAL 

— Display amount of rain recorded between start and end at coords x, y. 



You build a graphical interface that shows a map with many cities, and want to ensure 
that once a user has chosen a starting and ending dates Initial and Final moving the 
mouse across the map will at each step display the rainfall at the corresponding map 
position. This means that when calling the procedure show_rainfall for each 
mouse move event we should treat its first two arguments differently from the other 
two: 



The application sets start and end from Initial and Final. 

The GUI library mechanism will fill in a fresh x and y — event data — each time 
it triggers the event. 
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To achieve this effect, simply subscribe an agent that uses open arguments for the first 
set and closed arguments for the second set, as in /2/: 



mouse move. subscribe (agent show_rainfall (?, ?, Initial, Final ) 191 



(This could also use an explicit target as in /8/; the target could be closed or itself open.) 
The generality of this mechanism lets you tweak an existing routine to fit a new context: 
the subscriber freezes certain operands at subscription time, and leaves the others for 
the publisher to provide, as event data, at the time of event publication. 

The benefit here is that the agent lets us reuse an existing four-argument routine, 
show_rainfall, at a place were we need a routine with only two arguments. 

With other mechanisms such as the ones studied later in this chapter we would have 
to use two variables and write an explicit wrapper routine: 



Initial, Final: DATE 

— Start and end of rainfall data collection period 

show_rainfall_atJnitial_and_final (x, y: INTEGER) is /10/ 

- Display amount of rain recorded at x, y between Initial and Final. 

do 

show_rainfall {Initial, Final, x, y) 

end 



For a few routines and event types this approach is acceptable. When scaled up to real 
applications, it generates noise code that pollutes the architecture, making the program 
harder to understand, maintain and extend. 

Agents and the Event Library help avoid these pitfalls and build stable solutions on 
both the publisher and subscriber sides, with minimum connection code between the two. 



4 The Observer Pattern 



To provide more perspective on event-driven architectures and the design of the Event 
Library, this section and the next two examine other approaches. 

First, the “Observer Pattern”. As presented in the hook Design Patterns [6], it was 
one of the first descriptions of a general event-driven scheme. 

The following figure illustrates the general structure of that solution. For ease of 
comparison with the rest of this article the names Observer and Subject used in the 
original have been changed to SUBSCRIBER and PUBLISHER. APPCLASS and 
LIBCLASS denote typical examples of effective (concrete) classes, one describing a 
typical subscriber and the other a typical publisher. 
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(implemented) 
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^ Inherits 
from 



Client 

(uses) 



Figure 5: Observer Pattern architecture 

Surprisingly, in the basic design it’s the publishers that know about their observers, as 
shown by the direction of the client links on the figure: a publisher gets a new observer 
through the procedure attach and can remove it through detach. There is no equivalent 
to register on the subscriber side; in the primary example illustrating the pattern [6] — 
a clock that publishes ticks and two subscribers, both of them clock displays, one analog 
and the other digital — the subscriber objects get created with respect to a publisher, 
through a constructor (creation procedure) of the form 



make (p: PUBLISHER) is 

- Initialize this object as a subscriber to subject. 

do 

p. attach (Current) 

end 



(where Current is the current object (also called self, this, Me in various 0-0 
languages), so that the digital clock display gets created as 



create digital_display. make (clock) 



(in C-i-i-/Java/C# style: digitalDisplay = new DigitalDisplay (clock)). 

An immediately visible limitation of the pattern is that it lacks a general solution 
for the publisher to pass information to the subscriber. That doesn’t matter if all that 
characterizes an event is that it occurs. But many events will also need, as we have seen, 
to transmit event data, such as the mouse position for a mouse click. The Patterns book 
notes this issue (([6], page 298) and mentions two models for passing information, 
“push” and “pull”, each implying even more coupling between the publisher and the 
subscriber. Each requires extra coding on both sides, taking into account the specific 
type of information being passed. 
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No reusable solution seems possible here — short of an explosion of the number of 
classes, as will be seen in the .NET model’s approach in the next section — without both 
genericity and a tuple type mechanism as used by the Event Library. The Event Library 
represents event data through the generic parameter to EVENT_TYPE: when you 
introduce a new event type that generates, say, three pieces of information of types A, B 
and C, you will declare it of type EVENTTYPE [TUPLE [A, B, C]]. Then the routine that 
you subscribe must take arguments of types A, B, C. This takes care of the connection, 
but is not possible in the C++/Java framework, used in most published discussions of 
patterns with the exception of the work of Jezequel, Train and Mingins [8]. 

The Observer Pattern design raises two other immediate objections: 

• The creation procedure — make or the corresponding C++ constructor — must be 
written anew for each subscriber class, leading to useless repetition of code, the 
reverse of object technology principles. 

• It’s too restrictive to force subscribers to register themselves with publishers at 
creation time, not only because subscriber classes may already exist and have 
other creation requirements, but also because the subscribers should be able to 
subscribe later. 

We can alleviate both criticisms, at least in part, by adding to the class SUBSCRIBER a 
procedure subscribe which, on the subscriber side, mirrors what attach provides on the 
publisher side, and uses attach in its implementation: 



subscribe (p: PUBLISHER) is 

- Attach current subscriber to p. 

do 

p. attach (Current) 

end 



This extension explicitly makes subscribers clients of their publishers. But other 
problems remain. 

One is that a publisher sends notification of an event by calling a procedure update 
in each subscriber. The procedure is declared as deferred (abstract) in class SUBSCRIBER 
and effected (implemented) in each specific observer class such as APPCLASS to describe 
the subscriber’s specific reaction to the event. Each publisher keeps a list of its subscribers, 
updated by attach and detach; when it triggers an event, it traverses this list and calls 
update on each element in turn, relying on dynamic binding to ensure that each subscriber 
uses its own version. But this means that altogether a subscriber may register only one 
action! As a consequence, it may subscribe to only one type of event, except for the trivial 
case of handling several event types in the same way. This is severely restrictive. An 
application component should be able to register various operations to various publishers. 
The Event Library places no limit, for a subscriber, on the number of calls of the form 
some_control.some_event_type. subscribe (agent some_routine). 
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The discussion in the Patterns book acknowledges the issue and proposes a solution 
([6], page 297): add one argument to update to represent the publisher, which will pass 
Current when calling update to let the subscriber discriminate between publishers. But 
this is not satisfactory. Since there is still just one update procedure in each subscriber, 
that procedure will have to know about all relevant publishers and discriminate between 
them — a step back to the kind of know-them-all, consider-each-case-in-tum decision 
schemes from which object technology tries to free software architectures. Worse, this 
means a new form for procedure update, with one extra argument, invalidating the 
preceding class design for PUBLISHER and implying that we can’t have a single 
reusable class for this concept. Reusability concerns yield to general guidelines that 
have to be programmed again, in subtly different ways, for each new application. 



More generally the need for the subscribers to know the publishers is detrimental 
to the flexibility of the architecture. The direction of this knowledge relation is not 
completely obvious, since the last figure, drawn before we added subscribe to the 
pattern, only showed (like the corresponding UML diagram in the original Observer 
Pattern presentation) a client link from the publisher to the subscriber. That link indicates 
that each publisher object keeps a list of its subscribers. It has no harmful effect on the 
architecture since the text of publisher classes will, properly, not list subscribers. 



Subscriber classes, however, do mention the publisher explicitly. In the pattern’s 
original version, that’s because the constructor of a subscriber uses the publisher as 
argument; our addition of subscribe as an explicit procedure made this requirement 
clearer. It causes undesirable coupling between subscribers and publishers. Subscribers 
shouldn’t need to know which part of an application or library triggers certain events. 



Yet another consequence is that the Observer Pattern’s design doesn’t cover the 
case of a single event type that any number of publishers may trigger. You subscribe to 
one event type from one publisher, which the subscriber’s text must name explicitly. 



It is also not clear with the Observer Pattern how we could — as discussed under 
“Avoiding glue” in section 3 — connect without glue code an existing business model 
and an existing event-driven interface library. 



The Event Library overcomes all these limitations: publishers publish events of a 
certain event type; subscribers subscribe to such event types, not to specific publishers. 
The two sides are decoupled. All the specific schemes discussed in the Observer Pattern 
presentation are still possible as special cases. For all this extra generality, the interface 
is considerably simpler; it involves no abstract class and no inheritance relationship; it 
places no particular requirement on either subscriber or publisher classes, which can be 
arbitrary application or library elements. All a class must do to become a publisher or 
subscriber is to create objects of the appropriate type and call the desired features on 
them. In addition the solution is based on a reusable class, not on a design pattern, 
meaning that it does not require programmers to code a certain scheme from a textbook 
and change some aspects (such as the arguments to update) for each new application; 
instead they just rely on ready-to-use components. 
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It is legitimate to ask what caused the design of the Observer Pattern to miss the 
solution described here in favor of one that appears to be harder to learn, harder to use, 
less powerful, less reusable, and less general. Some of the reasons seem clear: 

• Although solutions had been published before, the Design Patterns book was one 
of the first times the problem was approached in its generality, so it’s not surprising 
that it didn’t produce the last word. The simplest solution doesn’t always come first, 
and it is easier to improve an original idea than to come up with it in the first place. 
This observation is also an opportunity to note that this article’s technical criticism 
of the Observer Pattern and other existing designs only make sense when 
accompanied by the obvious acknowledgment of the pioneering insights of the 
patterns work and other more recent developments. 

• The simpler and more advanced solution is only possible, as we have already noted 
in the case of event data representation, because of advanced language features: 
genericity, tuples, agents. The work on design patterns has been constrained by its 
close connection with C++ and then Java, both of which lack some of these features 
while sometimes adding their own obstacles. Take this comment in the presentation 
of the Observer Pattern: “Deleting a [publisher object] should not produce dangling 
references in its [subscribers]” ([6], page 297), followed by suggestions on how to 
avoid this pitfall. This reflects a problem of C++ (lack of standard garbage 
collection support) and has an adverse effect on the pattern. 

• The Patterns work endeavors to teach programmers useful schemes. This is far 
from the goal of object technology, the Eiffel method in particular, which seeks to 
build reusable components so that programmers do not have to repeat a pattern that 
has been identified as useful. 

We may also see another reason as possibly even more fundamental. The Observer 
Pattern design uses the wrong abstractions and in the process misses the right 
abstraction. Talk of right and wrong may sound arrogant, but seems justified here in 
light of the results. The abstractions “Subscriber” and “Publisher” (Subject and 
Observer in the original), although attractive at first, turn out to be too low-level, and 
force application designers to make relevant classes inherit from either SUBSCRIBER 
or PUBLISHER, hampering the reuse of existing software elements in new subscribing 
or publishing roles. Choosing instead Event type as the key abstraction — the only one 
introduced so far for the Event Library — leads to a completely different design. 



With all the attraction of new development tools, concepts and buzzwords, it is easy 
to forget that the key to good software, at least in an object-oriented style (but is there 
really any other path?), is a task that requires insight and sweat: the discovery of good 
abstractions. The best hope for dramatically decreasing the difficulty and cost of 
software development is to capture enough of these abstractions in reusable 
components. Design patterns are a useful and sometimes required first step of this 
effort, but are not sufficient since they still require each developer to learn the patterns 
and reimplement them. Once we have spotted a promising pattern, we shouldn’t stop, 
but continue to refine the pattern until we are able to turn it into a library ready for off- 
the-shelf reuse. 
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5 The .NET Event-Delegate Model 

Probably inspired by the Observer Pattern but very different in its details, an interesting 
recent development for the spread of event-driven design is the Microsoft .NET object 
model, which natively supports two concepts directly related to event-driven design: 
delegates, a way to encapsulate routines into objects, and event types. The presence of 
these mechanisms is one of the principal differences between the .NET model and its 
most direct predecessor, the Java language; delegates, introduced in Microsoft’s Visual 
J++ product, were at the center of Sun’s criticism of that product [19]. 

We will examine how events and delegates address the needs of event-driven design. 

The technology under discussion is not a programming language but the “.NET 
object modef’ providing a common substrate for many different languages. (Another 
article [14] discusses how the common object model and the programming languages 
manage to support different languages with their own diverse object models.) 

The .NET delegate-event model is quite complex, as we found out in surveying it 
for a book on .NET [15]. The present description is partial; for a complete picture see 
the book. 

C# and Visual Basic .NET, the two main languages directly provided by 
Microsoft to program .NET, have different syntax generally covering similar 
semantics — the semantics of the .NET object model. Event-delegate programming 
is one of the areas where the two languages show some significant differences; we’ll 
stay closer to the C# variant. 

The Basis for Delegates 

The .NET documentation presents delegates as a type-safe alternative to function 
pointers. More generally, a delegate is an object defined from a routine; the principal 
operation applicable to such an object is one that calls the routine, with arguments 
provided for the occasion. That operation — corresponding to the feature call applicable 
to Eiffel agents — is called Dynamicinvoke in the basic .NET object model. 

The notion is easy to express in terms of the more general agent concept introduced 
earlier. Assuming, in a class C, a routine of the form 



r(a1:A-, b1\ B) 



with some argument signature, chosen here — just as an example — to include two 
argument types A and 6, .NET delegates correspond to agents of the form 



agent r 



/ 11 / 



agent x.r 



IMI 



or 
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for X of type C. In either case, the delegate denotes a wrapper object for r. an object 
representing r ready to be called with the appropriate arguments. You would write such 
a call (still in Eiffel syntax for the moment) as 



your_delegate. call {[some_A_value, some_B_value]) 



/ 13 / 



where your_delegate is either of the above agents. /1 3/ has exactly the same effect as a 
direct call to r. 



r {some_A_value, some_B_yalue) 


/14/ 


X. r {some_A_value, some_B_value) 


/15/ 



and hence is not interesting if it’s next to the definition of your_delegate. The interest 
comes if the unit that defines your_delegate passes it to other modules, which will then 
execute /1 3/ when they feel it’s appropriate, without knowing the particular routine r 
that the delegate represents. 

The uncoupling will often go further, in line with the earlier discussion: the defining 
unit inserts your_delegate into an event-action table; the executing unit retrieves it from 
there, usually not knowing who deposited it, and executes call — Dynamicinvoke in 
.NET — on it. 

So far things are very simple. A delegate is like a restricted form of agent with all 
arguments open. There is no way to specify some arguments as “closed” by setting them 
at agent definition time, and leave some others open for filling in at agent call time, as 
in our earlier example mouse_move. subscribe (agent show_rainfall (?, ?, Initial, Final) 
191. To achieve that effect you would have to write a special wrapper routine that 
includes the open arguments only and fills in the closed arguments to call the original, 
in the style of show_rainfall_at_initial_and_final /lO/. 

The only difference between the delegate form without an explicit target, /ll/, and 
the form with x as a target, /1 2/, is that the first is only valid in the class C that defines 
r and will use the current object as target of future calls, whereas the second, valid 
anywhere, uses x as target. The direct call equivalent is /14/ in the first case and /15/ in 
the second. There is no way with delegates to keep the target open, as in the Eiffel 
notation agent {TARGET_TYPE).r, to achieve such an effect you have again to write a 
special wrapper routine, this time with an extra argument representing the target. 

In the examples so far the underlying routine r was a procedure, but the same 
mechanisms apply to a delegate built from a function. Then calling the delegate will 
return a result, as would a direct call to r. 

So the basic idea is easy to explain: a delegate is an object representing a routine 
ready to be called on a target set at the time of the delegate’s definition and arguments 
set at the time of the call. 
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The practical setup is more complicated. A delegate in .NET is an instance of a 
class that must be a descendant of a library class, Delegate, or its heir MulticastDelegate, 
which introduces the feature Dynamicinvoke. We won’t go into the details — see [15] 
— because these classes and features are not for direct use. They have a special status 
in the .NET runtime; programmers may not write classes that inherit from Delegate. It’s 
a kind of magic class reserved for use by compiler writers so that they can provide the 
corresponding mechanisms as language constructs. In Eiffel, the agent mechanism (not 
.NET-specific) readily plays that role. C# with the keyword delegate and Visual Basic 
.NET with Delegate provide constructs closely mapped to the semantics of the 
underlying .NET classes. 

Here is how it works in C#. You can’t directly define the equivalent of agent rbut 
must first define the corresponding delegate type: 



public void deiegate AB_de!egate {A x, B y); 



/ 16 / 



In spite of what the keyword delegate suggests, the declaration introduces a delegate 
type, not a delegate. 

The .NET documentation cheerfully mixes the two throughout, stating in places [16] that a 
delegate “w a data structure that refers to a static method or to a class instance and an instance 
method of that class'\ which defines a delegate as an object, and in others [17] that ‘‘‘"Delegates are 
a reference type that refers to a Shared method of a type or to an instance method of an objecf 
which, even understood as ‘"‘"A delegate is...”, says that a delegate is a type. WeTl stick to the 
simpler definition, that a delegate wraps a routine, and talk of delegate type for the second notion. 

A delegate type declaration resembles a routine definition — listing a return type, here 
void, and argument types — with the extra keyword deiegate. 

Armed with this definition you can, from a routine rof a matching signature, define 
an actual delegate that wraps r. 



AB delegate r_delegate = new AB delegate ( r); 



/ 17 / 



The argument we pass to the constructor is the name of a routine, r. This particular 
instruction is type-wise valid since the signatures declared for the delegate and the 
routine match. Otherwise it would be rejected. A delegate constructor as used here is 
the only context in which C#, and more generally the .NET model, allow the use of a 
routine as argument to a call. 

Instead of new AB_delegate (r) you can choose a specific call target x by writing 
new AB_delegate (x. r); or, if r is a static routine of class C, you can use new 
AB_delegate ( C. r). (A static routine in C-l-l- and successors is an operation that doesn’t 
take a target.) 

All we have achieved so far is the equivalent of defining the agent expression agent 
r or agent x. r. Because of typing constraints this requires defining a specific delegate 
type and explicitly creating the corresponding objects. The noise is due to the desire to 
maintain type safety in a framework that doesn’t support genericity: you must define a 
delegate type for every single routine signature used in event handling. 
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Equipped with a delegate, you’ll want to call the associated routine (see /13/). This is 
achieved, in C#, through an instruction that has the same syntactic form as a routine call: 



AB_delegate {some_A_value, some_B_value)\ 



/ 18 / 



Visual Basic .NET offers corresponding facilities. To define a delegate type as in /1 6/ 
you will write: 



Delegate Sub AB_delegate (x As A, y As B); 



To create a delegate of that type and associate it with a routine as in / 1 7/: 



Dim r delegate As New AB delegate (AddressOf r); 



The operator AddressOf is required since — unlike in C# — you can’t directly use the 
routine name as argument. 

Events 

Along with delegates, .NET offers a notion of event. Unlike the Event Library’s 
approach, the model doesn’t use ordinary objects for that purpose, but a special built-in 
concept of “event”. It’s a primitive of the object model, supported by language 
keywords: event in C#, Event in Visual Basic .NET, which you may use to declare 
special features (members) in a class. 

What such a declaration introduces is actually not an event but an event type. Here 
too the .NET documentation doesn’t try very hard to distinguish between types and 
instances, but for this discussion we have to be careful. When a .NET class Button in a 
GUI or WUI library declares a feature Click as event or Event it’s because the feature 
represents the event type “mouse click”, not a case of a user clicking a particular button. 

In the basic event handling scheme, the declaration of any event type specifies an 
associated delegate type. That’s how .NET enforces type checking for event handling. 
It all comes together in a type-safe way: 

1 • A delegate represents a routine. 

2 • That routine has a certain signature (number and types of arguments, and result if a 

function). 

3 • That signature determines a delegate type. 

4 • To define an event type, you associate it with such a delegate type. 

5 • Given the event type, any software element may trigger a corresponding event, 

passing to it a set of “event arguments” which must match the signature of the 
delegate. This matching is statically checkable; compilers for statically typed 
languages, and otherwise the type verifier of the .NET runtime, will reject the code 
if there is a discrepancy. 







256 Bertrand Meyer 



For step 4, Visual Basic .NET lets you specify a routine signature without explicitly 
introducing a delegate type as you must do in C#. Internally the VB.NET compiler will 
generate a delegate type anyway. We’ll restrict ourselves to the C# style, also possible 
in VB.NET. You can declare an event type as 



public event ABjdelegate Your_event_type ; 



/ 19 / 



where the last item is what’s being declared; the delegate type that precedes, here 
AB_delegate, is an extra qualifier like public and event. 

What this defines is a new event type such that triggering an event of type 
Your_event_type will produce event data of a type compatible with the signature of 
AB_delegate; in this example, the event will produce a value of type A and a value of 
type B. As another example you might declare 



public event Two_coordinate_delegate Click ; 



to declare an event type Click whose triggering will produce two integers corresponding 
to the mouse coordinates. This assumes (compare /16/): 



public void delegate Two coordinate delegate (int x, int y); /20/ 



Note again that a particular mouse click is an event, but Click itself denotes the general 
notion of a user clicking the mouse. 

Such event type definitions are the counterpart of the declarations of instances of 
EVENT_TYPE in the Event Library. Here, however, we have to introduce a new type 
declaration, referring to a delegate type, in each case. The reason is clear: the .NET model 
has neither tuples nor genericity. In the Event Library we could declare for example 



mousejcHck. £\/£/VT_TYP£[TL/P/.£[/A/T£G£R, INTEGER\] 



always using the same generic base class, EVENT_TYPE, and varying the generic 
parameter as needed. The equivalent of Your_event_type /1 9/ would use 
EVENT_TYPE [TUPLE [A, 6]]. In .NET, we have to introduce a new delegate type each 
time, and refer to it in declaring the event type. 

Connecting Delegates to Event Types 

We can now declare a delegate type corresponding to a certain routine signature; 
declare and create a delegate of that type, associated with a particular routine of 
matching signature; and define an event type that will generate event data also 
matching the delegate’s type, so that the data can be processed by the routine. We 
need a facility enabling a subscriber to connect a certain delegate with a certain event 
type for a certain control. 
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We know the general idea: record a triple — control, event type, delegate — into 
an event-action table. In the .NET model and especially C#, however, the mechanism is 
expressed at a lower level. You will write 



some_target.Some_event_type += somedelegate; 



for example 



your_button. Click += Two_coordinate_delegate; 



where the highlighted += operator means “append to the end of a lisf ’. This appends the 
delegate to the list associated with the target and the event type. Such a list 
automatically exists whenever some_target is of a type that, among its features, has an 
event type Some_event_type. Then if a publisher triggers an event, the underlying 
.NET mechanisms will traverse all the lists associated with the event’s type, and execute 
their delegates in sequence. 

Collectively, the set of all such lists constitutes the equivalent of the event-action 
table. The subscriber, however, will have to know about the individual lists and manage 
them individually. The only operations permitted are += and its inverse -= which 
removes a delegate. 

The introductory discussion of event-driven design pointed out that in the general 
case each association we record is not just a pair (event type, action) but a triple, 
involving a control. The .NET model’s basic association mechanism 
this_controLthis_event_type += this action directly enforces this style. But then it 
doesn’t cover the simpler case of subscribing to events that may occur anywhere, 
independent of any control. The Event Library gave us that flexibility: since an event 
type is just an object, you may create it at the level of the application III, or local to a 
particular control object such as a button 151. You can achieve the former effect in .NET 
too, but this will require defining and creating a pseudo-control object and attach the 
event type to it, another source of extra code. 

Raising Events 

We haven’t yet seen the publisher side. To raise an event of a type such as 
Your_event_type or Click you will, in C#, use the event type name as if it were a 
procedure name, passing the event data as arguments. Unfortunately, it is not enough to 
write Click (x_coordinate, y_coordinate) or, in the other example, Your_event_type 
(some_A_value, some_B_value). The proper idiom is 



if (Click != null) 

{Click (this, x_mouse_coordinate, y_mouse_coordinate);} /21/ 



The check for null is compulsory but can only be justified in reference to 
implementation internals. The name of the event type, here Click, denotes an internal 
list of delegates, to which you don’t have access. (You can apply += and -=, but not 
to the whole list, only to the list for one control, such as yourbutton. Click.) If it’s null 
because no delegate has been registered, trying to raise the event would cause an 
incorrect attempt to access a non-existent data structure. 
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It is incomprehensible that the mechanism puts the responsibility for this check to 
the publisher, for every triggering of any event. In the design of an API, one should 
avoid requiring client programmers to include an operation that’s tedious to code and 
easy to forget, raising the risk that applications will experience intermittent failures. 
Probably because of that risk, the documentation for .NET recommends never writing 
the above code /21/ to raise an event directly, but encapsulating it instead in a routine 



protected void OnClick (int x, int y) 
{if (Click != nuii) 

Click (this, X, y); 

} 



then calling that routine to publish the event. The documentation actually says that you 
“must” use this style, including naming the routine OnEventType, although in reality it’s 
only a style recommendation. The strength of the advice indicates, however, the risks 
of not doing things right. 



In comparing the .NET approach with the Event Library, we should also note that .NET’s triggering 
of events requires some underlying magic. In the Event Library, the consequence of 
mouse_click, publish (x, y) is to execute the procedure publish of class EVENT_TYPE. That 
procedure looks up the event-action table to find all agents that have been associated with the 
mouse_click event type, an ordinary object. The table implementation is a plain HASH_TABLE from 
the standard EiffelBase library. You can see the whole implementation (only if you want to, of 
course) by looking up the source code of EVENT_TYPE. If you are not happy with the 
implementation you can write a descendant of EVENT_TYPE that will use different data structures 
and algorithms. In .NET, however, you have to accept that the instruction to register an event type, 
such as your_button. Click += your_delegate, somehow updates not only the list Click attached to 
your_button but also the mysterious global list Click which you can’t manipulate directly, and in fact 
shouldn’t have to know about except that you must test it against null anyway. So you have to trust 
the .NET runtime to perform some of the essential operations for you. Of course the runtime 
probably deserves to be trusted on that count, but there is really no reason for such mysteries. 
Implementing the action-event table is plain application-level programming that doesn’t involve 
any system-level secrets and should have been done in a library, not in the built-in mechanisms of 
the virtual machine. 



Event Argument Classes 

If you have been monitoring the amount of extra code that various rules successively 
add to the basic ideas, you have one more step to go. For simplicity, our example event 
types. Click and Your_event_type, have relied on delegate types by specifying 
signatures directly: two integer arguments for Click /20/, arguments of types A and B in 
the other case / 1 6/. 

The recommended style is different. (Here too, the documentation suggests that this 
style is required, whereas it’s in fact just a possible methodological convention.) It 
requires any delegate type used with events — meaning, really, any delegate type — to 
have exactly two arguments, the first one an Object representing the target and the 
second a descendant of the library class System. EventArgs. In our examples, you 
would declare 
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// Compare with /16/: 

public void delegate AB_delegate (Object sender, ABEventArgs e) 



// Compare with /20/: 

public void delegate Two_coordinate_delegate (Object sender, 

TwoCoordinateEventArgs e) 



with special classes ABEventArgs, describing pairs of elements of types A and B, and 
TwoCoordinateEventArgs describing pairs of integer elements representing mouse 
coordinates. For an event that doesn’t generate event data, you would use the most 
general class System. EventArgs. 

The reason for this rule seems to be a desire to institute a fixed style for all event 
handling, where events take exactly two arguments, the details of the event data being 
encapsulated into a specific class. 

The consequence, however, is an explosion of small classes with no interesting 
features other than their fields, such as mouse coordinates x and y. In ordinary object- 
oriented methodology, the proliferation of such classes — really record types in 0-0 
clothing — is often a sign of trouble with the design. It is ironic that mechanisms such 
as delegates succeed in countering a similar proliferation, arising from the presence of 
many “command classes”, used for example in the Undo-Redo pattern [10]. 
Reintroducing numerous System. EventArgs classes, one per applicable signature, is a 
step backwards. 

The resulting style is particularly heavy in the case of events with no data: instead 
of omitting arguments altogether, you must still pass this (the current object) as Sender, 
and a useless object of type System. EventArgs — an event data object containing no 
event data. Such overkill is hard to justify. 

In the absence of compelling arguments for the System • EventArgs style, it would seem appropriate 
to advise .NET event programmers to disregard the official methodological rule. The style, 
however, is used heavily in the event-driven libraries of.NET, especially Windows Forms for GUI 
design and Web Forms for WUI design, so it’s probably there to stay. 

An Assessment of the .NET Form of Event-Driven Design 

The event-delegate mechanism of .NET clearly permits an event-driven style of design. 
It lies at the basis of Windows Forms and Web Forms, both important and attractive 
libraries in the .NET framework. We must keep this in mind when assessing the details; 
in particular, none of the limitations and complications encountered justifies returning 
to a Java approach where the absence of a mechanism to wrap routines in objects causes 
even more heaviness. 

The amount of noise code is, however, regrettable. Let’s recapitulate it by restarting 
from the Event Library model, which seems to yield the necessary functionality with 
the conceptually minimal notational baggage. On the publisher side we must, returning 
to the mouse click example: 

El 'Declare an event type click: EVENTJTYPE [TUPLE [INTEGER, INTEGER]] 
typically as a once function that creates the object. 

E2 'For every occurrence of the event, publish it: click, publish (x, y). 

On the subscriber side, to subscribe a routine r, we execute, once: 

E3 ‘your button. click. subscribe (agent r) 
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Here is the equivalent in .NET, again using C#. Some element of the system (it can be 
the publisher or the subscriber) must: 

D1 'Introduce a new descendant ClickArgs of EventArgs repeating the types of 
arguments of r. This adds a class to the system. 

D2 'Declare a delegate type ClickDelegate based on that class. This adds a type. 

Then the publisher must: 

D3 'Declare a new event type ClickEvent based on the type ClickDelegate. This adds a 
type. 

D4 'Introduce a procedure OnClick able to trigger a Click event, but protecting it against 
the null case. The scheme for this is always the same, but must be repeated for every 
event type. 

D5 'For every occurrence of the event, create an instance ofthe ClickArgs class, passing 
X and y to its constructor. This adds a run-time object. 

D6 'Also for every occurrence of the event, call Click with the newly created object as 
argument. 

The subscriber must, to subscribe a routine r. 

D7 'Declare a delegate rDelegate of type ClickDelegate. 

D8 'Instantiate that delegate with r as argument to the constructor (this step can, in C#, 
be included with the previous step as a single declaration-initialization, see HI!). 

D9 'Add it to the delegate list for the event type, through an instruction of the form 
you r_button. Click += rDelegate. 

In the case of an event type that is not specific to a control, it is also necessary, as we 
have seen, to add a class describing an artificial control. (With the Event Library you 
just remove the control, your_button, from E3.) 

To all this encumbrance one must add the consequences of the delegate 
mechanism’s lack of support for closed arguments and open targets, as permitted by 
agents. These limitations mean that it is less frequently possible, starting from an 
existing application, to reuse one of its routines directly (“without glue”) and plug it into 
an event-driven scheme, for example a GUI or WUI. If the argument signature is just a 
little different, you will need to write new wrapper routines simply to rearrange the 
arguments. More glue code. 

The combination of these observations explains why examples of typical event- 
driven code that would use a few lines with the Event Library can extend across many 
pages in .NET and C# books. 

This does not refute the observation that .NET essentially provides the needed 
support for event-driven design. The final assessment, however, is that the practical use 
of these mechanisms is more complicated and confusing than it should be. 
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6 Events for Web Interfaces in ASP.NET 



As a complement to the preceding discussion of .NET delegates and events it is 
interesting to note that the .NET framework does offer a simple and easy-to-learn 
mechanism for building event-driven applications. It’s not part of the basic Common 
Language Runtime capabilities, but rather belongs to the application side, in the Web 
Forms mechanism ofASP.NET. Internally, it relies on the more complex facilities that 
we have just reviewed, but it provides a simpler set of user facilities. The “users” here 
are not necessarily programmers but possibly Web designers who will, from Web pages, 
provide connections to an underlying application. So the scope is far more limited — 
ASP.NET is a web development platform, not a general programming model — but still 
interesting for this discussion. 



ASP.NET is a set of server-side tools to build “smart” Web pages, which provide 
not only presentation (graphics, HTML) but also a direct connection to computational 
facilities implemented on the Web server. Because ASP.NET is closely integrated with 
the rest of the .NET framework, these facilities can involve any software implemented 
on .NET, from database operations to arbitrarily complex programs written in any 
.NET-supported language such as C#, Visual Basic or Eiffel. 



An event-driven model presents itself naturally to execute such server operations in 
response to choices — button click, menu entry selection. . . — executed by a visitor to 
the Web page. The screen shown at the beginning of this article was indeed extracted 
from an ASP.NET application: 



@ http://guyana.ise/instant.net/display_time.aspx - Microsoft Internet Explorer 

File Edit View Favorites Tools Help 

Back ■' ^ I W*| y ' Search Favorites Media 

: Address http ://guyana.iseyinst ant. net/display Jime.aspx 



What time is it? | 23[14:00.0974384 



Figure 6: A Web User Interface under ASP.NET 



If the visitor clicks What time is it?, the current time of day appears in the adjacent text field. 



The code to achieve this is, even using C#, about as simple as might be hoped. The 
whole text reads: 
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<html> 

<body> 

<form runat="server"> 

<asp:Button OnClick = "display_time" 
Text = "What time is it?" runat = server/> 

<asp:TextBox id = "Output" runat=server/> 

</form> 

</body> 

<script language="C#" runat=server> 

private void display_time (Object sender, EventArgs e) 
{Output. Text= DateTime. Now.TimeOfDay.ToString();} 

</script> 

</html> 



The first part, the <body>, describes the layout of the page and the second part, <script>, 
provides the associated program elements, here in C#. 

The <body> describes two ASP.NET controls: a button, and a text box called 
Output. ASP.NET requires making them part of a <form> to be runat the server side. 
The first highlighted directive sets the OnClick attribute of the button to display_time, 
the name of a procedure that appears in the <script> part. That’s enough to establish the 
connection: when a Click event occurs, the procedure display_time will be executed. 

The <script> part is C# code consisting of a single procedure, display_time, which 
computes the current time and uses it to set the Text property of the Output box. 

This does what we want: a Click event occurring in the button causes execution of 
display_time, which displays the current time in the Output box. 

The time computation uses class DateTime, where feature Now gives the current date and time, of 
type Date; feature TimeOfDay, in Date, extracts the current time; and ToString produces a string 
representation of that time, so that we can assign it to the Text feature of the TextBox. 

Such simplicity is possible because ASP.NET takes care of the details. Since ASP.NET 
knows about the Click event type, controls such as asp:Button include an CnClick 
property, which you can set to refer to a particular procedure, here display_time. As a 
result, we don’t see any explicit delegate in the above code; .NET finds the name of the 
procedure display_time, and takes care of generating the corresponding delegates. 

The only hint that this involves delegates is in the signature of display_time, 
which involves two arguments: sender, of type object, and e, of type EventArgs. In the 
recommended style, as we have seen, they are the arguments representing event data, 
which delegate methods are expected to handle. Someone who just learns ASP.NET 
without getting the big picture will be told that (object sender, EventArgs e) is a magic 
formula to be recited at the right time so that things will work. 

Clearly, the .NET machinery translates all this into the standard event-delegate 
mechanism discussed in the previous section. But it is interesting to note that, when the 
target audience is presumed less technical — Web designers rather than hard-core 
programmers — .NET can offer a simple and clear API. 

The Event Library provides similar simplicity in a more general programming model. 
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7 Event Library Complements 

The essential properties of the Event Library were given at the beginning of this 
discussion (section 2). Here are a few complementary aspects, to indicate perspectives 
for more specialized uses. 

The library is available for free download, in source form, from se.inf.ethz.ch. Another reference 
[2] provides more details. 

Basic Features 

First let’s examine some uses of the class and of the two features already introduced. 
The class is declared as 



EVENT_TYPE [EVENT_DATA -> TUPLE] 



meaning that the generic parameter represents an arbitrary tuple type. The two basic 
features, as we have seen, are publish and subscribe. 

To introduce an event type you simply declare an entity, say your_event_type, with the 
type EVENT_TYPE [TUPLE [A, B, ...]] for some types A, B, ..., indicating that each 
occurrence will produce event data containing a value of type A, a value of type B and 
so on. If there is no event data use an empty tuple type as parameter: 
EVENT_TYPE [TUPLE []]. 

your_event_type will denote an ordinary object — an instance of EVENT TYPE — 
and you may declare it using any of the generally available techniques. One possibility, 
as we have seen, is to make it a “once function” so that it will denote a single run-time 
object, created the first time any part of the software requests it. You may also attach it 
to every instance of a certain class representing a control, for example as a “once per 
objecf’ function. Many other variants are possible. 

The two basic procedures have the signatures 



subscribe {action: PROCEDURE [ANY, EVENT_DATA]) 
publish (args: EVENT_DATA) 



The type PROCEDURE [G, H], from the Kernel Library, describes agents built from any 
procedure declared in a descendant class of G and taking arguments conforming — 
when grouped into a tuple — to H, a tuple type. Here this means that for EVENT_TYPE 
[TUPLE [/A, 6, ...]] you may subscribe any procedure, from any class, that takes 
arguments of types A, B, .... (For details of agents see [4] or [11].) 

The procedure publish takes an argument of type TUPLE [A, B, ...] — a sequence 
of values such as [some_a_value, some_b_value] denoting a tuple — enabling a 
publisher to trigger an event with appropriate event data through 



your_event_type. publish {[some_a_value, some_b_value]) 



as in the earlier example /3/. 
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Introducing Specific Event Types 

If for a certain event type you know the exact event data constituents, you can avoid 
using tuples by defining a specific heir of EVENT_TYPE. You might use this technique 
to cover a category of mouse events including left click, mouse click, right click, 
control-right-click, mouse movement etc. which all produce event data of a type 
MOUSE_POSITION represented by an existing class such as 



class 

MOUSE_POSITION 
feature - Access 
x: INTEGER 

— Horizontal position 

y: INTEGER 

— Vertical position 

... Other features (procedures in particular) ... 

end 



Publishers of mouse events might have access to an object current_positlon of type 
MOUSE POSITION representing the current mouse coordinates. By default they would 
trigger an event through calls such as 



control_rlght_click. publish {[current jpositlon.x, current_posltion.y]) 1221 



But it may be more convenient to let them use the object current position directly. 
If you define 



class 

MOUSE_EVENT_TYPE 

inherit 

EVENTjyPE [TUPLE [INTEGER, INTEGER]) 
feature - Basic operations 

publish _position (p: MOUSE_POSITION) is 

- Trigger event with coordinates of p. 

do 

publish {[p.x, p.y]) 

end 

end 



you can use this class rather than EVENT_TYPE to declare the relevant event types such 
as control_right_click, left_click, mouse_movement and so on, then publish mouse 
events, instead of 1221, through 
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control_right_click. publish_position (current_position) 



or even, if you give class MOUSE_EVENT_TYPE access to current_position, enabling 
it to include a procedure publish_current_position with no argument, through just 



control_right_click.publish_current_position 



Classes such as MOUSE_EVENT_TYPE correspond, in the .NET model, to specific 
descendants of System. EventArgs. The difference is that you are not required to 
define such classes; you’ll introduce one only if you identify an important category 
of event types with a specific form of event data, globally captured by an existing 
class, and — as a convenience — want to publish the event data as a single object 
rather than as a tuple. In all other cases you’ll just use EVENT_TYPE directly, with 
tuples. So you avoid the proliferation of useless little classes, observing instead the 
object technology principle that enjoins to add a class to a system only if it 
represents a significant new abstraction. 

Subscriber Precedence 

If several agents are subscribed to an event type, the associated routines will by default 
be executed, when events occur, in the order of their subscription. To change this policy 
you may directly access the list of subscribers and change the order of its elements. To 
facilitate this, class EVENT_TYPE is a descendant of LIST [ROUTINE [ANY, TUPLE[]], 
so that all the operations of the EiffelBase class LIST are applicable. 

Although such uses of inheritance are appropriate — see the detailed discussion in [10] — they 
run contrary to some commonly held views on 0-0 design methodology. It would be possible to 
make EVENT_TYPE a client rather than heir of LIST by including a feature subscribers of type 
LIST [ROUTINE [ANY, TUPLE[]]; although making the class less easy to use, this change would not 
affect the rest of this discussion. 

The principal factor in this decision to provide access to the list of subscribers was 
successful user experience with the EiffelVision 2 multi-platform GUI library [5], 
which follows the same convention. Reusing the EiffelBase list structures gives clients 
a whole wealth of list operations; the default subscribe is an extend, the operation that 
adds an element at the end of a list, but you can also use all the traversal operations, 
replace to replace a particular element, put_front to add an element at the beginning, the 
list deletion operations and others. This differs from .NET approach: 

• In .NET, you have to consider an event type as a list. Here you can just use 
subscribe without bothering or knowing about lists. Only for advanced uses that 
need fine control over the subscriber list will you start manipulating it directly. 

• In .NET, as noted, the list is always local to a control. Here it’s just a standard list 
object and may appear anywhere in the software structure, at the level of the 
application or local to another object. 

• The delegate lists associated with .NET events are very special structures, with only 
two applicable operations, += and -=. Here, they are general lists, to which you can 
apply all the EiffelBase list features. 
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Ignoring Some Publishers 

Subscribers can be selective about an event’s originating publisher. By default an event 
will cause the execution of subscribed routines regardless of the publisher. Call 
ignore_publisher (p: ANY) to exclude from consideration any event triggered by p. To 
ignore events except if they come from specific publishers, use consider_only (p: 
ARRAY [ANY]). To include a specific publisher explicitly, use consider publisher (p: 
ANY). To cancel all subscriptions, use ignore_all_publishers; to reset to the default 
policy, use consider_all_publishers. These procedures are cumulative: a call to any of 
them complements or overrides the policy set by previous calls. To find out the resulting 
status you may use ignored_publishers and considered publishers, both queries 
returning an ARRAY [ANY], the later meaningful only if the boolean query 
specific_publishers_only returns True. 

To ignore all events temporarily and start considering them again, use 
suspend subscription and restore_subscription. Unlike the ignore and cons/der variants 
these do not make any permanent change to the set of considered publishers. 

This last set of facilities lends itself to criticism of pointless “featurism”. As noted, 
however, such extra functionality does not harm simple uses of the library. It may have 
to be adapted or removed in the future. 

8 Software Engineering Lessons 

The first goal of this presentation has been immediate and pragmatic: to present the 
Event Library as a general tool for building event-driven software solutions. We may 
also draw some more general observations. 

Limitations 

The Event Library — like the other approaches surveyed — has so far been typically 
used for sequential or quasi-sequential applications, such as GUI development. 
Although its default ordering semantics is clear (procedures subscribed to the same 
event type will be executed, when an event occurs, in the order in which they have been 
subscribed), a generalization to full parallel computation would require precise rules on 
synchronization in the case of concurrent events. 

In addition, the presentation of the mechanisms has not included any discussion of 
correctness; such a discussion should be based on the contracts associated with the 
routines that we encapsulate in agents. 

Concurrency and correctness issues are clear candidates for further extensions of 
this work. 

The Virtue of Simplicity 

The word “simple” has occurred more than a few times in this presentation. Although 
claiming that something is simple doesn’t make it so, we hope that the reader will have 
noticed the small number of concepts involved in using the Event Library. 

This concern for simplicity applies not only to the library but also to the underlying 
language design, which attempts to maximize the “signal-to-noise ratio” both by 
providing powerful constructs, such as agents, and minimizing the noise by avoiding 
the provision of two solutions wherever one will do. 
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Although it may be tempting to dismiss the search for simplicity as a purely esthetic 
concern, the results seem clear when we compare the effort it takes for an ordinary user 
— an application builder who wants to use an event-driven library — to implement the 
Observer Pattern or use the .NET mechanisms (as discussed in the “assessment” at the 
end of section 5) rather than relying on the Event Library. 



The Search for Abstractions 



The key to the Event Library’s simplicity is in the choice of its basic abstraction. 
Previous solutions used different ones: 

• The Observer Pattern relies on abstractions “Subjecf’ and “Observer” which, 
however intuitive, are not particularly useful since they have no relevant features. 

• The .NET model produces complicated programs because it insists on defining a 
new delegate type — a new abstraction — for every routine signature to be used in 
handling events, and a new event type — again a new abstraction, with its own 
name — for every kind of event that a system may have to process. In the example 
discussed, it requires a new delegate type for procedures that take two integer 
arguments (where the Event Library simply uses an Eiffel agent expression, relying 
on genericity to ensure typing) and a new class to describe the mouse click event 
type. This leads to name and code explosion. 

Both cases seem to result from what has been called “taxomania” [10]: overuse of 
inheritance and introduction of useless classes. 

The Event Library identifies, as its key abstraction, the single notion of event type, 
characterized — as any proper abstraction in the abstract-data-type view at the basis of 
object technology — by relevant features: a subscriber can subscribe to be notified of 
events of a given type, and a publisher can publish an event of a given type. This choice 
of abstraction makes all the difference. 



Lines of Research 



This discussion has emphasized a certain path to software construction where the main 
task is to search for the right abstractions. 

Such emphasis may seem remote from the concepts that seem currently to dominate 
discussions of design methodology, from UML and Aspect-Oriented Programming to 
Extreme Programming and Agile Methods. Indeed there is nothing new in the idea of 
identifying the problem’s abstractions. But in light of the tendency to take object 
technology for granted [12], it is useful to note that resolving design problems may 
follow not just from new techniques but from the creative application of known 
principles. Good 0-0 design requires going back repeatedly to the basic question: 
“What are the main data abstractions behind this problem?”. 
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From Patterns to Components 

One of the design concepts that has amply proved its usefulness is the idea of design 
patterns. The patterns work has been instrumental in helping to identify and classify 
important algorithmic and architectural schemes. 

When assessed against reuse goals, however, design patterns seem to go the other 
way, possibly contradicting some of the ideas that have made object technology 
attractive. Patterns are techniques that developers must learn and implement, like 
repertoires of traditional algorithms and data structures that one learns as a student and 
applies as a programmer. Coming after object and component technology, patterns seem 
to imply a return to recipes which, however elegant, must be applied afresh by every 
developer in every project. 

This view that reusing packaged components is preferable to repeatedly 
handcrafting specific solutions leads to what we may call the Pattern Elimination 
Conjecture', that in the long term any useful pattern should be discarded as a pattern, and 
replaced by reusable components with a clear, simple, directly usable interface. Here 
the originators of the pattern idea would respond that typical patterns are too 
sophisticated to be encapsulated into components; but then the conjecture would assert 
that this difficulty of going from patterns to components is due to two factors: 

• The limitations of the programming languages that served to describe the original 
patterns. (The “Prototype” pattern, for example, disappears as a pattern in Eiffel to 
become a direct application of the Kernel Library’s built-in cloning mechanism.) 

• Possibly insufficient effort or insight in previous attempts to turn patterns into 
components. 

The Pattern Elimination Conjecture implies no criticism of the pattern idea; to the 
contrary, its recognizes the essential contribution of patterns to identifying the right 
components, part of what the reuse literature calls “domain analysis”. It states that the 
natural goal for a pattern, once identified, is to cease being a pattern and become 
packaged as a component. As noted in [10], it’s a natural ambition for object technology 
to make any statement of the form “X considered harmful” self-fulfilling — as soon as 
X, whatever it is, has been proved useful — by the simple observation that if it’s useful 
it should be componentized. 

This article’s analysis of the Observer pattern and its introduction of the Event 
Library confirm the Pattern Elimination Conjecture in one case, since it’s easier to use 
the library than to learn the architecture of the Observer pattern and apply it to a new 
program. This is of course just one example. Work by Karine Amout and the author (see 
[1]) is currently exploring whether this partial result can be generalized to other 
important design patterns as described in the literature. 

Types and Instances 

It has been noted [10] [13] that publications on object technology too often use the terms 
“class” and “object” for one another. The prevalence of this confusion is surprising, as 
there is nothing difficult here: a class is a model, an object is an instance of such a 
model; classes exist in the software text, objects existing in memory at execution time. 
Yet one continues to come across design documents that state proudly that a program 
will include “an Employee objecf’. 
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Some would argue that insisting on the distinction is just being fussy, and that 
readers understand what is meant in each case. Without having an absolute way to 
know, we may recall the lack of any attempt, in the .NET documentation, to distinguish 
between event types and events, or between delegate types and delegates, and 
conjecture that a more careful approach might have led to a different choice of basic 
abstraction and to a mechanism easier to understand and use. 

Programming Language Constructs 

Our final observation addresses the role of programming languages. The solution 
applied by the Event Library is made possible by the combination of a number of 
language features beyond the basic object-oriented concepts: 

• Genericity (the key to avoiding a proliferation of little event and delegate classes), 
which a satisfactory object model should include in addition to inheritance [9]. 

• Tuple types (also important for this purpose, thanks to their support for variable- 
length sequences). 

• Constrained genericity (used in the notation EVENT_DATA -> TUPLE in the 
declaration of EVENT_TYPE) to ensure that certain generic arguments can only 
represent tuples). 

• Agents (and their typing properties). 

• The possibility of using open as well as closed arguments in an agent, and of 
keeping the target open if desired (the key to avoiding a proliferation of glue code). 

• Once functions (taking care of the problems of object initialization and sharing 
without breaking the decentralization of object-oriented architectures). 

• Multiple inheritance (essential in particular to the structure of the underlying 
EiffelBase library). 

• Covariance (for the needed type flexibility, in spite of the associated type checking 
issues). 

With the growing acceptance of object-oriented ideas as a basis for new languages, 
there may be a tendency to assume that all 0-0 models are essentially equivalent. They 
are not. The features listed, many of them not supported by most 0-0 languages, make 
the difference in the ease of use, extendibility and reusability of the solutions 
encountered in this discussion. 

Scope 

Event-driven design is attractive in a number of situations illustrated by the examples 
of this article. It would be useful to conclude with a precise analysis of how it relates to 
other design styles, and how wide a range of applications it encompasses. We can, 
however, offer no firm answer on either count. 

The most natural comparison is with concurrent computation mechanisms. Event- 
driven design indeed assumes some concurrency between the publishers and the 
subscribers, but that concurrency remains implicit in the model. Analogies that come to 
mind are with CSP [7], with its input and output events, and with the Linda approach to 
concurrent computation [3] whose general scheme involves clients depositing 
computational requests into a general “tuple space” which suppliers then retrieve and 
process based on pattern matching. We have not, however, explored such analogies 
further. Some work, already noted [18], is intended to replace event-driven design by 
concurrent computation mechanisms. 
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We are also not able to provide a clear assessment of the scope of the design style 
presented in this discussion. It undoubtedly works well in its usual areas of application, 
mainly GUI and now WUI building. How general is the idea, illustrated in figure 3, of 
publishers throwing events like bottled messages into the ocean, with the hope that 
some subscriber will pick them up? It may be a powerful paradigm that can affect the 
structure of many systems, not just their relation to their user interfaces; or maybe not. 

On one issue, language-related, we now have unambiguous evidence: the 
usefulness of equipping an object-oriented language with a way to encapsulate routines 
into objects, such as Eiffel’s agents or the delegate facility of.NET. The introduction of 
agents initially raised concern that they might in certain cases compete with the more 
traditional 0-0 constructs. Extensive experience with the mechanism has dispelled this 
concern; agents have a precise place in the object-oriented scheme, and in practice there 
is no ambiguity as to where they should be used and where not. The library-based 
scheme of event-driven computation described in this article is a clear example of when 
agents can provide an indispensable service. 
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Abstract. Reactive and hybrid systems are modeled by games where 
players make strategic decisions in a temporally discrete manner. The 
dynamics of players use dense or discrete time. In order to guarantee in- 
variance and inevitability properties, the proponent moves are restricted 
by “winning guards” . The winning strategy determined by these guards 
does not exclude any initial state from which a winning strategy exists. 
Sets of such initial states constitute winning regions and are defined by 
hxed points. The iterates which yield winning regions are structured as 
unions of iterates which yield winning guards. 



1 Introduction 

The theory of games deals with interaction between dynamics. This is why it 
helps in understanding control systems, hybrid ones and reactive ones. For ex- 
ample, a control system can be presented as a noncooperative game where the 
controlling and controlled components are respectively the proponent and the 
opponent [Isa65]. There are various kinds of games [Ba098, Tho95]: plays may 
have a finite or infinite duration; time may be discrete or dense; players may co- 
operate or not; their strategic decisions may be taken continuously or discretely; 
each one may involve a finite or infinite set of choices; moves may be carried out 
in sequence or in parallel; they may be atomic, in one step, or durative, in any 
number of steps; goals may be qualitative or quantitative; informations on states 
may be perfect or imperfect; winning strategies may use additional memory or 
not. 

A (strategic) decision is the selection of a move according to the strategy 
of a player. In “discrete-decision games”, these decisions are separated by non- 
infinitesimal time-intervals. Hybrid systems can be modeled by discrete-decision 
games where the control moves by the proponent are atomic transitions [TLSOO] . 
In general, the temporal discreteness of decisions is compatible with dense-time 
dynamics for proponents as well as for opponents; thus, the granularity of dy- 
namics can be adapted and the roles of players can be exchanged. For the limited 
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problems tackled in this paper, it suffices to consider discrete-decisions games re- 
stricted as follows: the goals are qualitative; the information on states is perfect; 
the choice sets are finite; the winning strategies do not use additional memory. 

Games are characterized by the dynamics of players, their roles and the win- 
ning conditions. Dynamics are expressed here by “processes”, i.e. sets of trajecto- 
ries. Roles determine cooperation or non-cooperation of players and are expressed 
by “pre-maps” associated with disjunctive or conjunctive decision modes. Pre- 
maps generalize predicate transformers [Dij76] and yield “preconditions”, viz. 
sets of adequate initial states for given decision modes, processes and winning 
conditions. Winning conditions express goals for players and are represented by 
distinctive processes called “specifications”. The binding of roles of players to 
their dynamics, viz. of pre-maps to processes, results in alternating, interacting 
processes called “coprocesses” . A game thus consists of a coprocess and a spec- 
ification. These components correspond to a graph-based arena and a winning 
set in the case of a discrete-time finite-state game [GTW02 (§2)]. 

The goal of the present work is the iterative synthesis of winning strategies for 
discrete-decision games. Iterative methods provide a structured framework for 
the systematic development of effective algorithms and they scale up well from 
finite domains to infinite ones. They can be used here thanks to the discreteness 
of decisions and the finiteness of choice sets. Game analysis follows iterative 
methods as a rule, especially for the generation of winning regions. Glassical 
methods of game synthesis are based on the extraction of strategy functions 
from winning regions and are partially iterative [Ba098, Tho95]. 

In order to elaborate iterative synthesis techniques, we represent winning 
strategies by “winning guards” which restrict the domains of proponent moves. 
These guards ensure that all permitted plays satisfy the winning conditions; they 
do not need additional memory; their union includes each state in the winning 
region of the proponent. Thus, they determine a complete, finite-memory, win- 
ning strategy for the latter. We tackle the two primitive properties of dynamics, 
namely invariance and inevitability; they constitute the first level in the Borel 
hierarchy [Tho95]. The winning guards are synthesized iteratively on the basis 
of fixed-point definitions of winning regions: the iterates which generate winning 
regions are structured as unions of iterates which generate winning guards. This 
approach follows a method developed for the synthesis of correct guards in ac- 
tion systems, which amount to cooperative games with atomic moves defined by 
predicate transformers [vLS79]. 

The paper is organized as follows. Processes, specifications and preconditions 
are defined in Section 2. Goprocesses, their preconditions and discrete-decision 
games are presented in Section 3. Iterative synthesis techniques for winning 
strategies are developed in Section 4. Section 5 discusses related, current and 
further work, and concludes with some reflections. 

The mathematical basis of the paper consists of a few results about lattices. 
Some developments are merely outlined. General formulations of definitions and 
properties may be replaced by typical instances. Proofs which are similar to pre- 
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vious ones may be summarized. The references indicate original, representative 
or recent works. 

Notational conventions The set of functions from A to i? is denoted hy A ^ B. 
A function application f{u) may be written f.u or fu when no ambiguity arises. 
Given a binary relation r, its converse {{x,y) \ (y,x) € r} is denoted by r“. The 
set of subsets of a set V is denoted by 2^. A Cartesian product V x V may 
be denoted by V“^. An interval {c | a < c < 6} is denoted by (a : h). The set 
of integers is denoted by W, and is the set of nonnegative real numbers. 
The symbol oo stands for * or oj. For a set B and a predicate E, we abbreviate 
(B yf 0) A (Vx e B : E) by V+x G B : E. 

We write fxX : [f.X] for the least fixed-point of a monotone function / in a 
complete lattice, and nX : [f.X] for the greatest one. The abbreviation A f.A 
stands for the equation A = y,X : [f.X], and similarly for =i,. Given the classical 
Knaster-Tarski Theorem, these fixed points are computable by transfinite itera- 
tions [Cou78, DNOO, GTW02 (§20)]. In a finite lattice, finite iterations suffice. If 
/ is continuous, e.g. /. U^g/Xi = Ui^if.Xi for any increasing chain (xj)igiv, then 
it suffices to use infinite iterations on the form = a, = f.X^^f For 

simplicity, iterative computations of fixed points are presented in terms of infi- 
nite iterations; versions using transfinite iterations can be obtained by systematic 
adaptations. 

2 Processes, Specifications, and Their Preconditions 

We present a compositional framework for processes a.k.a. behaviours, viz. sets 
of trajectories [Si96j. It allows for dense and discrete time and for temporal 
variants of classical operations of program composition. 

Specifications are distinguished processes. They may represent winning con- 
ditions. 

Pre-maps express selection modes. They yield preconditions which character- 
ize the begin-points of trajectories matching a given specification and selected 
according to a given mode. These preconditions are analogous to starting basins 
for dynamics, to preconditions for programs and to winning regions for games. 



2.1 Basic Processes and Operations 

Let y be a non-empty set of points, viz. values or states. Let T be a set of 
times, with a total order, a minimum element 0, a commutative and associative 
addition with 0 as identity, and possibly an infinite element uit- We may write 
u for ojt if no ambiguity arises, and we may use an identifier for a time set 
containing an infinite element. Examples of time sets are {0,1}, JR’^, or 

X IRj) with vector addition, lexicographic ordering and the infinite element 
(wjv, Wjfj+). An element of a Gartesian product T is finite iff all its components 
are finite. 
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A trajectory 6 is a pair {d, g) where Dur.b = d € T is the duration and 
g G (0 : d) ^ 17 is the graph; its begin- and end-point are respectively Beg.b = g.Q 
and End.b = g.d. A process B is a, set of trajectories, and a B-trajectory is an 
element of B. The duration of a process B is finite iff the duration of each B- 
trajectory is finite. 

Given d G T,P C V, the process [d]P is the set of trajectories with duration 
d and range P: [d\P = {{d,g) \ g G {0 : d) ^ P}. We may write [dJrP to recall 
the time set T of interest. The universal process over P is [ ]P = UdeTM-P; 
where T may include to. The process [*]P is [ ]P\[w]P. The universal process is 
[ ]V. The identity process Idp over P is [0]P. The identity process Id is Idy- 
The following set-operations can be used for processes: union U, intersection 
n, finite union finite intersection Hie/ for a finite set I, and complemen- 

tation \. We write —B for ([ ]V)\B if P C [ ]V, and — P for I7\P if P C V. 

A cone is a process where all trajectories begin with the same point. For 
B G []V,x G V, the process B(x) is the cone {b j b G B A {Beg.b = x)}. A 
process B is deterministic iff, for each x G V, the cone B{x) contains at most 
one trajectory. 

Let be c, d G T, c < d. The prefix 6(0 : c) of a trajectory 6 = (d, g) is the 
trajectory (c, d) such that Vt G (0 : c) : h.t = g.t. For B C [d\V, P(0 : c) is 
{6(0 : c) I 6 g P}. 

For a relation r C 17^, an r-6osed process P is {(1,5) | {g.O, g.l) G r} C [l]_jvF^. 
It is called a relational process. Similarly if P = |(l,p) | (g.(0, 0), (?.(1, 0)) G r} C 
[(1) 0)]wxiR+^- 

Assume a dense-time process P C [d\]p+V where d G lN,d > 1. Then the 
discrete-time sampling of P is the discrete-time process Bjn C [d]]NV defined by 
B]n = {{d,h) I : [ (d, g) G P A Vi G (0 : d) n W : h{i) = g{i) ] }. 

Similarly for time sets such as IN x or IN^^ x M^. 

Notes 

1. Relational processes allow to integrate the relation-based view of dynamics, 
as used for automata and programs, into the process-based one. The Carte- 
sian product P X P is isomorphic to the process [l]{o,i}d^ containing all the 
two-points trajectories with range P C V. The set P is isomorphic to the 
identity process Idp over P. 

2. The most abstract time-set is the singleton {0}. The abstract, binary time- 
set {0,1} consists of begin- and end-times only and may be used for atomic 
moves. Time sets such as IN and IR^ refine {0,1} and may be used for 
durative dynamics. The time set INoj x is super-dense. 

3. The infinite time w can be excluded by using [*]P or T\{a;}. When presenting 
a list of time sets which may include it, we often just give a few typical cases. 

2.2 Temporal Composition of Processes 

Basic operations for process composition are given in §2.1. Processes may also 
be composed by means of temporal forms of sequential, concurrent and iterative 
composition. 
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2.2.1 Temporal Composition Operations 

(a) Sequential composition The sequential composition of two processes 
Bi C [*]V and B2 C []V is 

Bi; B2 = { bi; &2 | G -Bi A 62 G i?2 A {End.bi = Beg.b2)}, 
where {di, gi); {(I2, 92) is (di + d2,g) 

such that 5(0 : di) = (71(0 : d\) and Vt G (0 : ^2) : 9-{di + t) = g2-t. 
The sequential composition of processes is fusion based: in the trajectory (61; 62), 
61 and 62 share the point End.bi = Beg.b2- This is also the case for sequential 
composition of relations and programs. 

Given a process B C [*]V, the repetition B” is defined as follows, where 
n,m £ IN, m < n: 

B° = Id, B™+i = B™; B. 

The pre-restriction of a process B C [ ]1A by a guard P CV is 
B = Idp;B. 

Thus, P ^ B = {6 I Beg.b £ P Ab £ B}, the cone B{x) equals {x} ^ B, and 
B = V ^ B.By convention, P^ ^ Bi = ^ Bi). 

(b) Concurrent composition Let Vi,V2,lAi x V2 C V. The local concurrent 
composition of Bi C [ jCi, B2 C [ ]V2 is 

Bi G B2 = { 61 G 62 I bi £ Bi A b'2 £ B'2 A {Dur.bi = Dur.b'2)}, 

where {d, gi) {d, g'2) is (d,g) such that Vt G (0 : d) : g.t = {gi.t,g2-t). 
The process Bi® B'2 C [ ](Ci x V2) is a Cartesian, isochronous composition of 
the local processes B\,B'2, called local branches. This composition is not com- 
mutative. The operator ® has priority over G and C. 

Let us now assume, for i G I,j £ J : Gi,G'j C Ci x V2, Bi C [ ]Vi, B' C 
[ ]^2, B = U,6/ Gi^Bi ® [ ]C2, and B' = IJ.^j G) ^ [ ]Ci G B'. Then, the 
(global) concurrent composition of B, B' C [ ]{V\ x V2) is 

B\\B' = Ue/yejG.nC' - Bi G B'. 

It is not commutative by definition of B, B'. In the (left) branch B, local processes 
Bi C []Vi are concurrent with universal local ones [ ]V2 and are restricted by 
global guards Gi. Note {Bi ® [ ]V2) n ([ ]Vi ® B') = Bi ® B'. Branches are 
processes and can be composed, for instance sequentially. The branch B may be 
written Gi — Bi, and similarly for the (right) branch B' . 

We have BiOB^ = Vi x C2 — Bi G B^ = (Vi x C2 ^ Bi || Vd x C2 — B'2). 
Local concurrency is introduced for presentation purposes. 

(c) Iterative composition Let B C [*]V. The finite and infinite iteration of 
the process B are respectively 

B* = /rX : [IdU (X;B)] and B“ = vY : [B-Y], 
defined in the complete lattice 2t of processes. The fixed point B* is the limit 
of the iteration = 0, = Id U B). The map X ^ Mid {X; B) 

is continuous, hence monotone, because {{{Ji^jN Bi); B) = \Ji^][^{Bi; B). As a 
consequence, B* = IJnew B"- 

Similarly, B“ is the limit of = [ ]V, = (B;T^"^). We have 

y(n+i) = = B”;(B;[] 1 A) C B^;[]V = 
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Notes 

1. To sum up, processes B C [ ]tV are mainly generated by the following rules: 
B-.:= B,\[d]P\[*]P\[]P\ 

BUB\BnB\ Ue/S, I ~B\ 

B-B I B\\B I 

where Ba <1 []tV, d GT, P C V, I is a, finite set, the Bi's generate processes 
and w G IN LI Primary processes Ba are constructed for example by 

automata, programs, or differential equations or inclusions. Accordingly, the 
composition operations on processes can be expressed by corresponding ones 
on transition systems or differential ones. 

2. Discrete-time processes resemble temporal programs in a discrete-time, 
interval-based temporal logic with sequential and iterative composition 
[Mos98]. They are related to processes in the semantics of communicating 
concurrent programs [Hoa85] . Communications are represented here by con- 
current readings in global states, viz. by global guards. 

3. For all P C P and di,d 2 G T, the process H = [di + d 2 ]P verifies the 

closure property H = H{0 : di);H{0 : d 2 ). Thus, the P-trajectories have 
no memory: any suffix of any trajectory is the prefix of another one. So to 
speak, H is full. This is akin to the semi-group axiom q ydi 

for flows generated by differential equations [BaC97]. In general, processes 
contain trajectories with memory. For instance, if P C [2]V contains a single 
trajectory, then B does not necessarily include B{0 : 1);P(0 : 1). 

4. Classical relational approaches use a binary time-set and abstract from the 
intermediate points appearing in compositions [Abr96, BaW98]. 

2.2.2 Non-Zeno Assumption In this paper, we assume the following: 

The time set contains a finite number of distinguished elements differ- 
ent from 0 and called non-Zeno times. The duration of each considered 
trajectory is bounded below by a non-Zeno time. 

This is a sufficient condition for excluding Zeno trajectories [DNOO, Lyg03]. 

Notes Let be lim„^i^ P" in an ultrametric structure [Ros 98] . 

1. Given the Non-Zeno assumption, each limit P^“ is the fixed point of a 
contracting map, using a prefix-based ultrametric distance du- Hence P^“ = 
P^“; [ ]V = P“. For example, d„( ([1]P)^“, (([1]P)^“; [ ]V) ) = 0, hence 
([l]P)-“ = ([1]P)--[]P = ([1]P)“. 

2. Consider processes Pq C [(1;0)]tP and Pi C Uc;6iR+ where 
T = X These processes may respectively model atomic control- 
transitions and durative plant-dynamics in hybrid systems [Lyg03] . To guar- 
antee the Non-Zeno assumption, the non-Zeno times (1,0) and (0,2“^°°) 
may for instance be used. 

In this case, the duration of each trajectory in the limit (Po;5i)^“ is 
the infinite time (w^v,Wjfj+). Hence, the duration of each trajectory in 
(Po; Pi)* U (Po; Pi)“ is either finite or infinite: heterogeneous durations such 
as (wiv,5.03) are excluded. 
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2.2.3 Properties 

(a) Sequential composition of processes is monotone and associative. 

(b) Concurrent and iterative compositions of processes are monotone. 

(c) For P,Q CV imd B C[]V, P ^ {Q ^ B) = {P n Q) ^ B. 

(d) For Vi, V2, V1XV2CV, [ ]Fi O [ ]C2 = [ ]{Vi x V2). 

(e) Assume Bi c[c\V, B2 Cl[]V are left branches, and B[ C [c]C, B'2 C [ ]C 
are right branches, for c € T\{u;}. Then 

{B,-,B 2 )\m-,B' 2 ) = {B,\\B[)-,{B 2 \\B' 2 ), 

{Bi^\\B'i^) = {Bi\\B'i)^ , where w € IN \J {*,w}. 

(f) Assume ri C , V2 C V^, r = { ((xi, X2), (yi, j/2)) | {xi,yi) G ri A 
{x2tV2) G r2} C (Vi X V2)^. Let Ri,R2,R be the ri~, r2~, r-based process, 
respectively. Then 



(g) i ?2 = R. 



2.3 Specifications 

Specifications are distinguished processes which express desired dynamical pat- 
terns. They result from a restricted family of composition operations which ab- 
stract from time. In this paper, we focus on an operation serving to display 
sequential patterns of process ranges and called “chop” [Mos 98 ]. Specifications 
are usually identified by IF, to remind of winning processes. 



2.3.1 Definitions The chop of two sets P, Q C V is the specification P Q = 
[*]P; [ ]Q. The chop of two specifications IF, IF' C [ ]F is the specification 
IF-^IF' = (IFn [*]F);IF'. 

The other composition operations for specifications are union, opposite, rep- 
etition and iteration; for tu G iV U {*,w}, the definition of IF'^ is (IF n [*]F)^. 
Specifications IF C [ ]F are thus generated as follows: 

W ::= P'-'Q I IF-^IF | IF U IF | - IF | IF^ (P, Q C F). 

Notations Given a trajectory b = (d,g), times t,t' G T such that t < t' < d, and 
P,QcV, 



b{t : t') G P^P iff Vs G (t : t') : g.s G P, 

b{t : t') G P^Q iff 3 s G (t : t')\{w} : b{t : s) G P^P A b{s : f) G Q'~^Q. 
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2.3.2 Properties Assume P,QcV. 

(a) P n Q = 0 P'~^Q = 0. 

(b) Given 6i, 62 € []V and End.bi = Beg.b2, 

bi\ &2 G P"Q 

= {hi G P'~'Q A 62 G Q'~'Q) V {hi G P'~' P A 62 G P'~'Q) in general, 
= 61 G P-^PA&2 G P-^Q ifQcP. 

For b = (1,5) G [l]_svG, we simply have 

b G P-^Q = {g.O, g.l) G (P n Q) x Q U P x (P n Q). 

(c) Let r C P X Q. Assume R C is r-based (§ 2.1). Then: 

R C P"(PU in general; 

Pc P"Q if p c gv g c P; p c p-^p if p = g. 

Proof: Let T = JV. For each & = (1, g) G P, we have 
b G R C [1]V by assumption on P. Hence 
b G [1](P U g) since r G P x g C (P U g) x (P U g). Hence 
b G Idp] [1](PU g); Mq since g.O G P, g.l G g. Hence 
6 G P"^(P U g)"^g by § 2.3.1. Hence 
P C P"^(P U g)'^g given 6 G P. 

(d) Chop is associative and monotone. 



2.3.3 Discrete Observability Assume P,QcV,dG IN,d > 1. Then, the 
chop P'~'Q is discretely observable in a trajectory b = {d,g) € [ ]jr+P iff the 
following holds, for A = P or A = Q and for all n G iV n (0 : d — 1) : 

{g{n),g{n + 1)) G A x A b{n : n + 1) G A^A, 

{g{n),g{n + 1)) G P x g b{n : n + 1) G P'~'Q. 

The chop P'~'Q is discretely observable in a proeess B C [ ]jr+P iff it is discretely 

observable in each P-trajectory. Similarly for time sets such as and IN x . 



2.3.4 Remarks 

Chop and temporal logic The following equalities illustrate the use of chop in 
temporal specifications [Mos98], and thus in the present ones: DP = P'^P, 

OP = V'~'P'~'V, PUQ = P'~'{P U g)'^g'^lA. The characteristic predicate of 
a set P is also denoted by P. Unlike chop, the until-operator U is not fusion- 
based; hence, P and Q can be disjoint. This explains the presence of P U g on 
the right-hand side (§2.3.2.c). The last occurrence of V is needed in case PldQ 
is followed by ^Q. The discrete-time next-operator 0P is not expressible using 
chops, which permit dense time. 

Processes and specifications A process B satisfies a specification W B C W, 
viz. B conforms to the pattern defined by W. For example, B C P'^'P and 
B' C Q^Q entail P; P' C P^Q. The choice of composition operations for 
specifications could be adapted without changing the main results; a relevant 
criterion could be the decidability of P C IF. 
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2.4 Pre-maps and Preconditions for Processes 

A pre-map ^ is a pre-image operator; it maps processes to functions from spec- 
ifications to subsets of V called preconditions: ^ G — > (211^ ^ 2^). The 

precondition ^B.W is the set M such that W contains the B-trajectories which 
begin with points in M and which are selected according to the decision mode 
associated with We say precondition for a set by abuse of language. 

As classical, we consider three decision modes for trajectory selection 
[BaW98, DNOO]: the disjunctive mode expressing existence, the conjunctive one 
expressing universality or inexistence, and the combined one expressing univer- 
sality and existence. They are respectively associated with the three pre-maps 
E, A and M, which are defined below and may be read pre-exists, pre-all and 
pre-all-exists. 

The pre-map of a sequential composition of processes equals a nested com- 
position of pre-maps of these processes. This allows to decompose a given chop 
into smaller ones. 

Notations 

Logical quantifiers: Lg = 3, = V, Lj^ = V+ (§1). 

Dualities: = A, A"^ = E. 

Meta-variables: G {E,A,.®}, G {E,.®}, ri,r]i G {E,A}, where 

i G IN . Thus we use C for a pre-map expressing at least existence, and rj for one 
of the dual pre-maps. 

2.4.1 Definitions Given a process B and a specification W, 

EB.W = {x I 3& G B{x) :h€W} = {x \ B{x) n W yf 0}, 

AB.W = {x\ybe B{x) :beW} = {x\ B{x) C W}, 

MB.W = {x I y+b G B{x) :b€W} = (AB.W) n (EB.W). 

In short, ^B.W = {x \ L^b G B{x) : b G W}. 

The cone B{x) is defined in § 2.1. The pre-map A allows blocking, viz. inex- 
istence of trajectories, but E and M forbid it: for instance, we have A%.W = V 
whereas E 0.W = 0 and M Iti.W = E n 0 = 0. Both A and M can be defined 
from E since AB.W = — EB. — W. 

Note There is an alternative way to define preconditions, in terms of sets of cones 
associated with a process B. Each set represents the selection mode defined by 
a pre-map; each selected cone is a subset of B: 

EB = {{&}|&Gi?}, 

AB = {B], 

MB = {B\B^lb}. 

Here, ^ G 2tl'^ ^ 2^''^ maps processes to sets of cones and ^B G 2^'"^ is a set 
of cones for any i? G 2t 1^. 

The precondition of ^B wrt. a specification W is then obtained as follows, 
where Pre G 2^^''^ ^ ^ 2^) is a generic pre-map: 

Pre.^B.W = {x \ 3 Bq G ^{B{x)) : Bq C W}. 
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2.4.2 Remarks 

Predicate transformers The pre-map is a temporal generalization of the 
predicate-transformer wp [Dij76]. For a given program, wp transforms a post- 
condition into a precondition, viz. a set of points into a set of points. For a given 
process, JE transforms a specification into a precondition, viz. a process into a 
set of points. Both wp and JE express universality and existence. 

Path quantifiers The pre-maps E and A are analogous to the path quantifiers 
in branching-time temporal logics [CGP99, DNOO]. The pre-map JE corresponds 
to no specific path-quantifier. 

Operational interpretation From any x in the precondition EB.W, there exists 
some B(x)-trajectory which belongs to W. To find one often requires a sys- 
tematic search among the B(x)-trajectories. On the other hand, from any x in 
JEB.W, each B(a;)-trajectory belongs to W and at least one exists. Exhaustive 
exploration is then not needed. It is thus worthwhile to replace the process B 
hy B' G B such that the precondition JEB' .W is as large as possible. 

2.4.3 Properties Assume P,Q CV, B,B' C [ ]V, and specifications W, W . 

(a) Begin set: (B.P^Q C P. 

(b) Duality: -EB.W = AB. - W. 

(c) Monotonicity: fB.W C C,B.{W U W'). 

(d) Chop decomposition for processes: given B C [*] V, 

E{B;B').P"Q 

= EB.P'-^Q'-^iEB'.Q-'Q) U EB.P-'iEB' .P-'Q) in general, 

= EB.P'-'{EBhP'-'Q) HQ CP. 

Proof by §§2.2.1. a, 2.3.2.b and the equality {P'~'P)'~'Q = P'~'Q. 

Similarly for JE instead of E : 

JE{B\ B').P''Q = JEB .P'- {JEB' .P'^ Q) ii Q c P. 

(e) For a deterministic process B (§ 2.1), EB.W = AB.W = JEB.W. Moreover, 
Eld.P-P = Ald.P-'P = JEId.P'-'P = P. 

(f) Case of pre-restrictions: by § 2.4.1, given Pi C V, Bi C [ ]V for i G I, 

E [j^eJ{P^ - B,).W = P^ n {EB^.W) 

A - B,).w = u AB^.W). 

In particular, A IJ Bi.W = f|ig/ ABi.W. 

Note Chop decomposition (d) allows to decompose a proof into sub-proofs. It 
is thus similar to compositional proof rules in interval temporal logic [Mos98, 
Eqn (1)]. In general, it does not hold for the pre-map A which permits blocking; 
for instance, A{B\%).P^Q = A%.P^Q = V whereas AB.P^ {Atb.P^Q) = 
AB.P-'V. 
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2.4.4 Three Classical Properties of Dynamics Fundamental properties of 
dynamics can be expressed in terms of preconditions. 

Let P CV. A trajectory b stays in P iS b € P'~'P. It reaches P iff 6 G V'~'P. 

(a) Invariance without Termination, a.k.a. Safety For each x in the precondition 
JEB‘^ ,P'~' P, each 5‘^-trajectory beginning with x stays in P and does not ter- 
minate, and at least one such trajectory exists. Given the Non-Zeno assumption 
(§2.2.2), non termination implies infinite duration. 

Similarly, for each x in EP“.P'~'P, there exists at least one P“-trajectory 
which stays in P and never terminates. This precondition is akin to a viability 
domain [Aub91]. 

(b) Inevitability with Invariance, a.k.a. Safe Reachability Assume Q C P. For 
each X in the precondition lEB* .P'^Q, all trajectories in the non-empty cone 
B*{x) stay in P and reach Q. 

The precondition MB^ .P'~'Q = MB* .P^fMB^ .Q'~' Q) contains the points 
x such that all trajectories in the non-empty cone B^(x) stay in P for a finite 
duration and afterwards stay in Q for an infinite duration. This is a persistence 
property and can be expressed in terms of (a), (b) and chop decomposition. 

(c) Liveness, a.k.a. Recurrence The precondition MB^ .{V'~' P)‘*’ contains the 
points X such that all trajectories in the non-empty cone P“(x) do, from each 
time value, reach P. 

Thus, the P“-trajectories beginning in this precondition verify the temporal- 
logic formula DOP 



2.5 Computation of Preconditions for Processes 

We present a procedure for computing preconditions fB.W. This procedure 
is not always effective because it does not treat all dense-time processes, and 
because limits of infinite or transfinite iterations may be needed. The procedure 
is effective at least in the case of discrete T and finite V. 

The computation oi fB.W follows the structure of B. The specification W is 
restricted to P^Q where P,Q CV. We first detail the computation of EP.P'^Q. 
The computation of MB.P'~'Q is similar and summarized in a last case. 



2.5.1 Case of Relational Processes If r C and R is the r-based process, 
then EP.P'^'Q results from elementary relational computations: 

EP.P-^Q 

= (P n Q) n r"{Q) U P n r“(P n Q) in general, or 
= P n r“(P n Q) if r C {—Q) X V, 

= Pnr“(g) ifPcQVQcP, 

= Pnr“(P) if P = Q. 
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Proof: Let T = IN. For each b= (l,g) G R : 

{l,g)eP-Q 

= g.O G P A {g.0,5.1} C Q V C PA 5 .I G Q by §2.3.2.b, 

= g.O e Pf]Q A g.l G Q V g.O G P A g.l G P D Q. 

Hence, 

EP.P-^Q 

= {xo I 3(xo, Xi) Gr:xoGPnQAxiG(5 V XoGPAxiGPnQ} 
by §2.4.1, 

= (PnQ)nr“((5) u Pnr“(Pn(5). 



2 . 5.2 Case of Sequential and Repeated Processes We repeatedly decom- 
pose chops (§2.4.3.d). 



2.5.3 Case of Concurrent Processes They are reduced to relational, se- 
quential or iterative processes, by distributivity and relational simplification 
(§2.2.3.e,f). 



2.5.4 Case of Iterative Processes Fixed points are defined and computed as 
follows. We assume Q C P CV, B c [*]V. 

(a) Preconditions for finitely iterated processes 
EB*.P'-'Q = g,Y ■.[QUEB.P-Y] 

This least fixed-point is defined in the complete lattice 2^^ of subsets of V, and 
it is computed by the iteration 

y(o) = 0^ r("+b = guEP.p-^r^”). 

The function Y 1 -^ Q U EB.P'~^Y transforms a set of points into a set of 
points since the precondition EP.P'^F is a set of points. Monotonicity follows 
from §§2.3.2.d, 2.4.3.C. Hence 

y(n+i) = y(«) u where = Q, = EB.P-'X^^\ 

The property = EP".P'~'g is verified by induction as follows, for n > 0. 

Basis: = Eld-P-^Q = PnQ = Q by defns §§2.1, 2.4.1. 

Induction step: assume = EP".P'^Q; then, 

x("+b 

= EP.P'^(EP”.P'^g) 

by the defn of and the induction hypothesis, 

= E(P; P”).P"^g by chop decomposition (§ 2.4.3.d), 

= EP"“*'^.P'~'g by defn of repetition (§ 2.2.1. a). 
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(b) Preconditions for infinitely iterated processes 
EB'^.P'-'P = vZ ■. [EB.P-Z]. 

This greatest fixed-point is defined in the complete lattice 2^, and is computed 
by the iteration 

Z(o) = P, = EB.P'-'Z^'^f 

Given § 2.4.3.a,c,d, = EB^ .P^{EB.P- P) C 

The property is proven by induction, as in (a). 

Notes 

1. For a repetition i?", we clearly have : this is the inductive 

property verified in (a). 

2. The simplifying assumption Q C P is not essential (§2.4.3.d). 

3. The term P^Y is similar to the constructs using Uq and Reach in [AsaOO, 
TLSOO]; cf. §2.3.4. 

4. The fixed point vZ : [EP.P"^Z] in 2^ equals vZ : \EB.P'~'{Z n P)] in 2^ . 
We use the first expression for simplicity. 



2.5.5 Case of Dense-Time Processes Assume P^Q is discretely observable 
(§ 2.3.3) in a dense-time process B, and Pjv is the discrete-time sampling (§ 2.1) 
of B. Then C,B.P'~'Q = C,Bjn ,P'~'Q which is computable by §2. 5. 1-4. 

The duration of the discrete steps depends on the regularity of the B- 
trajectories. By a suitable time re-scaling, any time quantum in B can match 
the time unit in Bj^. 



2.5.6 Case of .^-preconditions The computation of JEB.P'^'Q is defined 
by a systematic adaptation of §§2.5. 1-5, using chop decomposition (§2.4.3.d). 
In particular, 

MB*.P-Q = pY -.[Qyj MB.P-Y], 
computed in 2^ by 

= Q, 

y(n-Hi) = y(«) y where = Q, = JEB.P-X^^\ 

The property = JEB"^ ,P'~'Q, for n > 0, is verified as in §2. 5. 4. a. 

3 Coprocesses and Their Preconditions 

Introduction In order to express different interaction patterns, e.g. cooperation 
vs competition, we introduce “coprocesses” composed of applications of pre-maps 
to processes. That term hints at the interaction between processes bound to 
alternative decision- modes. The coprocesses Ei?o and ABi can be respectively 
seen as the proponent and the opponent in a finite, sequential, noncooperative 
game with two players. The max-min dynamics of this game can be defined by the 
iterative coprocess (Ei?o; Ai?i)*. The specification could be {—Wini)^Wino, 
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where Win^ and Win\ are the winning sets of states for the proponent and the 
opponent, respectively. 

Game dynamics can thus be described by coprocesses using A and E; sim- 
ilarly, game trees can be generated by and/or-programs [HarSO]. Coprocesses 
may also model reactive or hybrid systems, contracts [BaW98] or alternating 
transition systems [HenOO]. The interplay between the pre-maps E and A is 
characterized by that between 3 and V (§ 2.4.1). So, the interaction pattern in a 
coprocess is determined by the structure of pre-map alternations in it. 

Coprocesses and their preconditions are defined in the following Sections. 
These preconditions can also be understood in terms of associated cones we 
introduce informally. Given a coprocess S', an S-cone is a cone generated as 
follows: the components of its trajectories belong to component processes of S 
and are collected according to the corresponding pre-maps (§ 2.4.1-Note). As an 
example, let S be (EBi; JEB 2 )] then there exists one distinct S-cone ({ 61 }; B 2 ) 
for each trajectory b\ G Bi such that B 2 {End.bi) yf 0. The set of S-cones is 
equivalent to the game-tree for S. The precondition S.W is the set of points each 
of which begins at least one S-cone contained in W: from each such point, a 
winning strategy exists. 

Given a coprocess S, an S-trajectory is an element of an S-cone, i.e. a Bs~ 
trajectory where the process Bs is obtained by removing the pre-maps from S. 
The duration of S is finite iff the duration of each S-trajectory is finite. 

Specifications and coprocesses respectively correspond to temporal formulae 
and their models [GGP99]; pre-maps are similar to path quantifiers (§ 2.4.2). We 
do not use path quantifiers in specifications given the limited problems consid- 
ered in this paper. We use pre-maps in coprocesses in order to express different 
roles for players in games. 

3.1 Structure of Coprocesses 

A basic coprocess fB is the application of a pre-map ^ to a process B] it trans- 
forms a specification into a precondition, viz. ^B G 2ll^ ^ 2^. A concurrent 
coprocess is a concurrent composition of basic or concurrent coprocesses. A se- 
quential coprocess is a sequential composition of basic, concurrent or sequential 
coprocesses. An iterative coprocess is an iterative composition of basic, concur- 
rent or sequential coprocesses. A coprocess S' G 2t ^ 2^^ is a basic, concurrent, 
sequential or iterative coprocess. 

This stratified structure is restrictive: for instance, concurrent composition of 
sequential coprocesses is excluded. The resulting coprocesses are more tractable, 
and yet not trivial. 

The preconditions for basic and composed coprocesses are respectively de- 
fined in §2.4.1 and in the Sections below. Symbols for coprocess compositions 
are the same as for process compositions. 

3.2 Sequential Composition of Basic Coprocesses 

We define preconditions for sequential compositions of basic coprocesses only, in 
order to begin with a simple presentation of typical definitions and properties. 
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We assume are processes (i S IN), W,W' are specifications, and 

P,Q CV. 

3.2.1 Definition We first give a simple case, where Bi C [*]V, and then the 
m-ary one : 

(EBi;JEB 2 ).W = {x I 3bi G Bi(x) : V +&2 G B^iEnd.bi) : [bM G W}, 

• • • ; ■■■; ^mBm)-W 

= {x I G i?i(x) : • • • : L^^bi G Bi(End.bi-i) : 

• • • . L^^bm G B^(^End.bjji—i) . (6i, ■ ■ ■ , bi, ■ ■ ■ , G 11^}. 

A'^ote This precondition may be defined in terms of sets of cones; see the introduc- 
tion above and the note in §2.4.1. Assume S = (EBi; JEB 2 ). Let S{x) G 
be the set of A-cones beginning with x gV: 

S{x) = {{&i}; S 2 I G Bi{x) A {B 2 {End.bi) ^ 0)}. 

Then the precondition of S wrt. a specification W is 
Pre.S.W = {x\3B€ S{x) : B cW}. 

3.2.2 Properties We assume B\ C [*]V,B 2 C []V. 

(a) Duality: -{mBi; 772 ^ 2 ). W = {vT Bi; 77 $" B 2 ). - W. 

(b) Monotonicity: (Ci^i; C 2 B 2 )-W C (Ci^i; C 2 S 2 ).( 1 L U W), 

(c) Chop decomposition for basic coprocesses: 

(EBi-,JEB2).P--Q 

= EBi.P'~' Q'~' {JEB 2 -Q'~' Q) U EBi-P'^ {JEB 2 -P'^Q) in general, 

= EBi.P"{JEB2.P'^Q) ifQcP. 

Proof: by § 2.3.2.b, as for § 2.4.3.d. 

Similarly, 

(CiBi; C2B2).p-Q = CiPi.p^(C 2 P 2 .p^Q) if Q c p. 

(d) Case of pre-restrictions: assume Q C P C V, B c[]V, Pi C V, Bi C [*]V, 
for i G L By §3.2.1, as in §2.4.3.f, 

(E Ue7(P^ ^ P*); CB).P-Q = Uie, P^ C (EP,; C,B).P-Q, 

(A U,ez(P^ ^ Bi)- CB).P-Q = U (AP,; C,B).P-Q). 

Hence {JE[J-^j{Pi Bi)-,(B).P^Q equals the conjunction of these two 
preconditions, since (V+6 G B : E) = {3b G P : P) A (V& G B : E). 

3.3 Concurrent Composition of Basic Coprocesses 

We need to express a logical ordering between quantifiers, viz. between the pre- 
maps of branches, without introducing additional constraints on the dynamics. 

Assume Pi C [ ]Pi, P 2 C [ ]V 2 are processes, and W, W C [ ](Pi x V 2 ) are 
specifications. 
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3.3.1 Definition In the case of a local concurrent composition, we have 

= {(xi,X2) I G Bi{xi) : G B 2 {x 2 ) : 6i &2 G W}. 

E.g., (EBi (g) AB2).W = {{xi,X2) I 3&1 G Bi{xi) : V62 G B2{x2) : &i (g) &2 G W}. 

In the case of a global concurrent composition, where Gi,Gj C Vi x V 2 , Bi C 

[]Vi, C [ ]V 2 , we have for instance 

(EUe/G.-B. \\ JE[J^^jG' ^ B').W 

= {(xi,X2) \3i e I : [ {xi,X2) G Gi A G Bi{xi) : 

[ Vj G J : ( (xi, X2) G G' ^ V+6' G S'(x2) : & 6' G IE) 

A 3j G J : ( (xi,X2) G G'j A V+6' G B'^{x2) : &(g) 6' G IE)]]}. 



3.3.2 Properties Assume Bi,B2 are concurrent branches. 

(a) Duality: -(77iBiljr?2.B2).IE = Bi\\r]:^ B2). - W. 

(b) Monotonicity: (CiSij]C2S2).IE C (CiSij|C2S2).(IE U IE'). 



3.4 Sequential Composition with Concurrent Coprocesses 



Let be processes Bi C [*]Ei, B2 C [*]E2, B3 C [*]Es, B C [ ](Ei x E2), and 
specifications IE, IE' C [ ](Ei x E2), IE" C [ ]((Ei x V2) x E3). 



3.4.1 Definition We give a typical case: 

{{^iBi ^ 2 B 2 );^B).W = {(xi,X 2 ) 1 G Bi{xi) : L^^b 2 G 52(^2) : 

L^b G B{End.{bi (g) 62)) : ((^i ^2); b) G IE}. 

Cases with global concurrency are obtained by systematic adaptations (§ 3 . 3 . 1 ). 
The general definition of preconditions for sequential coprocesses is obtained by 
combining the definitions given here and in § 3 . 2 . 1 . The case of m-ary concurrent 
coprocesses is similar: e.g., 

((eiSi(g)C2B2)OC3B3).IE" 

= {((xi,X 2 ),X 3 ) 1 Lji&i G Bi{xi) : L^^b2 G 52(^2) : 

L4363 G S3(x3) : (&i (g) &2) (g) 63 G IE"}. 

Given a basic, concurrent or sequential coprocess S', the repetition S" is 
defined as follows, for n,m G IN and m < n: 

S° = M Id, S^+i = S'"; S. 
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3.4.2 Properties 

(a) Duality: ~{{riiBi\\r]2B2)-,riB).W = {{ri^BiWr]^ B2)',ri~B). - W. 

(b) Monotonicity: ((C1S1HC2B2); C ((C1S1HC2B2); CS).(Vb U ID')- 

(c) Chop decomposition for coprocesses: assume Q C P C V, S' is a basic, 
concurrent or sequential coprocess, S' is a basic or concurrent one, and both 
have a finite duration and only use the non-blocking pre-maps E or then 

(S; S').P-Q = S.P-fS'.P-Q). 

This property generalizes §3.2.2.c. Here is the proof for a typical case: 

((CiSi®C2B2);CS).p^Q 
= {{xi,X2) I Tci^i € Bi{xi) : G B2{x2) : 

L^b G B{End.{bi®b 2 )) : (( 61 ( 8 ) 62 ); 6 ) G P'~'Q} by defn § 3.4.1, 
= {(a;i,X 2 ) I ^ Bi{xi) : L(_^b2 G B2{x2) : 

(61 0 62) G P-{CB.P"Q)} by § 2.3.2.b, 

= {fiBi®C2B2).P-{CB.P-Q) by defn §3.3.1. 



3.5 Iterative Composition of Coprocesses 

3.5.1 Assumptions The fixed-point definitions of preconditions for iterative 
processes (§2.5.4) depend on chop decomposition for processes (§2.4.3.d). The 
same holds for iterative coprocesses wrt. § 3.4.2.C. A coprocess S to be iterated 
must thus verify the following conditions: 

(i) S \s & basic, concurrent or sequential coprocess with pre-maps E or lE only, 
(a) the duration S is finite. 

The Non-Zeno assumption (§ 2.2.2) also concerns coprocesses: for each considered 
coprocess S, the duration of each 5'-trajectory is bounded below by a non-Zeno 
time. 

The least and greatest fixed-points below generalize those defining precondi- 
tions for iterative processes. The structure of these fixed-point definitions match 
that of iterative coprocesses. 



3.5.2 Preconditions for Finitely Iterated Coprocesses 

S*.P'-Q = pY : [QUS.P-Y]. 

This fixed point is defined in the complete lattice 2^ and is computed by 

y(o) = 0, 

Thanks to monotonicity (§§2.3.2.d, 3.2.2.b), 

y(n-ei) = y(n) u x("), where A<o) = Q, = S.P'-'X^"\ 

The property = S'".P'~'Q is proven as in §2.5.4, using §§3.4.2.c, 3.5.1. 
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3.5.3 Preconditions for Infinitely Iterated Coprocesses 

S^.P-P = vZ : [S.P-'Z]. 

This fixed point is defined in the complete lattice 2^ and is computed by 
Z(o) = P, = S.P^Z^'^\ 

The property = S'^.P'^'P is proven as in §2.5.4, using §§3.4.2.c, 3.5.1. 

Given §§3.2.1, 3.4.1, the set is thus characterized by an w^v-length 

V/3 formula. 

3.6 Computation of Preconditions for Coprocesses 

The procedure for computing preconditions for coprocesses follows the stratified 
structure of coprocesses. It is not always effective (§2.5). We only tackle speci- 
fications on the form P^Q for Q C P C V. If Q C P does not hold, the general 
cases in §§2.3.2.b,c, 3.4.2.C should be used. 

Case of basic coprocesses See §2.5. 

Case of concurrent coprocesses See § 3.3.1. As an example, we detail the case of 
local relational branches. Assume, for i = 1,2 : ri C Vi x Vi, Ri is r^-based, and 
Q C P C Vi X V 2 . Then, by §§2.2.3.f, 2.3. 2.b, 

(CiPi G C,2R2)-P^ Q 

= {{xi,X2) I L^^{xi,yi) G n : Lq^{x2,V2) G T2 : {{xi,X2), (2/1, 2/2)) G P x Q} 
which is a relational computation. 

To reduce the duration of concurrent coprocesses, one may reduce that of 
concurrent processes by using distributivity properties (§2.2.3.e). 

Case of sequential and repeated coprocesses Their preconditions are decomposed 
into preconditions for basic or concurrent coprocesses, by repeatedly decompos- 
ing chops (§§3.2.2.d, 3.4.2.c). 

Case of iterative coprocesses The fixed points in § 3.5 are computed by iterations. 
Each iterate is computed using the previous cases since A is a basic, concurrent 
or sequential coprocess. 

3.7 Discrete-Decision Games and Winning Regions 

Games are pairs of coprocesses and specifications. Winning regions are their 
preconditions. The definitions are detailed hereafter. 

A (noncooperative, iterative) game coprocess is a coprocess S°° where the 
proponent is a distinguished coprocess occurring in S and using the pre-map E 
or M] the opponent is the remainder of S. A game is a pair {S°°, W) consisting 
of a game coprocess and a specification W. The winning region of a game 
(S'®®, IT) is the precondition S°° .W. Moves and plays are S- and 5'°°-trajectories, 
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respectively. The game is finite, resp. infinite, if the duration of the plays is finite, 
resp. infinite. 

Strategic decisions are made by players when their moves are selected, viz. 
when their pre-maps are elaborated. Given the stratification of coprocesses 
(§3.1), any two decisions generated by a coprocess S are generated either by 
a concurrent composition of coprocesses in S' or by a sequential or iterative one; 
they are then said to be concurrent or sequential, respectively. A coprocess S is 
a discrete-decision coprocess iff any two sequential decisions generated by S are 
separated by a time interval bounded below by a non-Zeno time. 

A discrete-decision game is a game (S°°, W) where S°° is a discrete-decision 
game-coprocess verifying two additional assumptions. Firstly, the proponent co- 
process C,B occurs at the left-most position in S', like a dominating existential 
quantifier: we seek a winning strategy for the proponent. Secondly, the choice set 
of the proponent is finite, namely i? is a finite union Bi or Gi Bi 
(§2.2.1.b) where each Bi is deterministic. We could thus use the more complete 
expression “discrete-decision, finite-choice, dynamical game”, where “dynami- 
cal” refers to dense- or discrete-time dynamics. 

The Non-Zeno assumption entails each coprocess is a discrete-decision one. 
Let us check this. For any two sequential decisions in any coprocess S, the first 
one is generated by a basic coprocess S'o in S. Hence their occurrence times are 
separated by at least the duration of an Ao-trajectory, which is bounded below 
by a non-Zeno time (§3.5.1). Hence S' is a discrete-decision coprocess. 

3.8 Related Work on Discrete-Decision Coprocesses 

We briefly discuss related work on discrete-decision coprocesses such as reactive 
and hybrid systems. The time set is x (§ 2.2.2); the time set may be 
represented by x {0}. We use relational processes R,R',Ri C [(1,0)]H and 
durative ones B,Bi C Ud6K+ c^)]^) for i = 1,2. In discussions such as the 
present one, we do not consider the difference between A and JE (§2.4.1). 

Coprocesses (Ei?; Ai?')“ on a finite state-space, e.g. in the case of Biichi 
automata, are treated in [BiiL69, TB70, RW89]. Simple cooperative coprocesses 
(Ei?)“ on infinite state-spaces are considered in [vLS79]. Noncooperative copro- 
cesses (Ei?; Ai?')“ on infinite state-spaces are studied in [MP95, BaW98]. The 
local concurrent case S‘^ = (Ei?i|| Ai? 2 )“ is investigated in [AMP95, Hen 00]; 
the precondition S.V'~'Q is analogous to the set (Q) in [HenOOj. 

Coprocesses (ER; AH)“ model the hybrid systems considered in [AMP95, 
AsaOO]. Richer coprocesses such as ((Ei?i|| AR 2 ); A(Ri|jH 2 ))“ model two con- 
current hybrid systems, with control transitions in i?i, R 2 and plant trajectories 
in Bi, B 2 , respectively [TLSOO] . Variant or dual forms of the until-operator are 
introduced in [AsaOO, TLSOO] to take the durative R-trajectories into account 
(§2.5.4-Note.3). 

Quasi-discrete games and games with K-strategies [Isa65] are discrete- 
decision games; they serve to approximate continuous-decision ones. 




Iterative Synthesis of Control Guards 291 



4 Iterative Synthesis of Winning Strategies 

4.1 Preliminaries 

4.1.1 Winning Transforms of Discrete-Decision Games Consider a 

discrete-decision game where the proponent is E_B (§3.7). The win- 

ning plays for the proponent result from the search-based selection- mode E. 
This mode is to be strengthened into the search-free one M (§ 2.4.2). 

As a consequence, we aim at restricting the proponent process B = Bi 
by the addition of guards Ci CV which exclude B-moves steering plays outside 
of W . Let Be be the union of pre-restrictions of the i?i’s, i.e. Be 
If the Ci’s only permit B-moves which steer plays inside the winning process W, 
they are winning guards. In this case, the proponent EB can be replaced in S by 
MBe- A winning transform of the discrete-decision game (S'°°,IT) is (5'“,IE) 
where Sc is the result of such a replacement. The winning transform represents a 
finite-memory strategy since the winning guards do not need additional memory. 
This winning strategy must be complete in the sense that S°° .W = the 

reduction of B to Be may not reduce the winning region. 

The goal is to construct such winning guards iteratively, given a discrete- 
decision game (5'°°,IT) and a proponent ElJ-gjUj, or ElJ-g^G^ ^ Bi in & 
concurrent coprocess. 



4.1.2 Synthesis Problems We consider two basic properties of dynamics 
(§2.4.4.a,b). Let P,QcV. 

(I) Invariance without Termination Given a discrete-decision game , P'~' P) , 

to find a winning transform (S'“, P'^P) with the same winning region. 

(II) Inevitability with Invariance Given a discrete-decision game (S'*, P'~'Q), to 
find a winning transform (S).,P'~'Q) with the same winning region. 



4.1.3 Solution Method We extend to coprocesses the method used for action 
systems [vLS79]. In the latter work, an action system amounts to an iteration 
(Ei?)°° of a basic, cooperative, relational coprocess on a finite or infinite state- 
space. The idea is simple: the iterates which yield a winning region C 

in) 

are structured as unions of iterates C) ' which yield winning guards Ci. The 
iteration function for is then refined into iteration functions for 

We reuse the fixed-point definitions of winning regions (§§ 3.5, 3.7). Thus, the 
chop decomposition (§3.4.2.c) is as useful for iterative synthesis as for iterative 
analysis (§3.6). Following §§2 and 3, the synthesis methods below are defined 
for dense and discrete time. However, as in §§2.5, 3.6, the iterative techniques 
we propose are discrete or use discretization. Again, these techniques in general 
require induction, and thus give rise to procedures which are not always effective. 
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4.1.4 Assumptions In the considered synthesis problems, we assume the fol- 
lowing: 

(a) S' = (EB; AS') where i? = i?i, , or S = ((Ei?|| AS'); AS") where 
is a left branch IJie/ ^ The proponent is E_B. 

(b) Each process Bi is deterministic. Hence Ei?i = MBi = ABi (§2.4.3.e). 

(c) The opponent coprocess does not block, viz. AB = JEB (§2.4.1). 
The assumption (a) may thus be replaced by S = (EB; MB') or S = 
{(EB\\MB');MB"). 

(d) S has a finite duration. 

(e) Q C P CV. 

Notes 

1. The coprocesses EB and (EH||Ai?') are respectively equal to (EH; A Id) 
and ((EH|| AH'); Aid), which are instances of (a). 

2. By assumption (b), the non-determinism of H is entirely expressed by the 
finite union (JjgjHi (§2.1). The choice set in EH is thus finite. We do not 
use the more general assumption H = IJjg/ MBi because the composition of 
coprocesses is restricted (§3.1). 

3. Assumption (c) can be ensured by taking B C [d\V where d is sufficiently 
small so that blocking H-trajectories are excluded in the time interval (0 : d). 

4. Condition (i) in §3.5.1 results from (c). Condition (ii) is (d). 

5. The simplifying assumption (e) is not essential (§2.4.3.d). 

4.2 Invariance without Termination 

A point is loosing if it begins a play which leaves the set P or terminates. Loosing 
points are iteratively removed from the initially given domains of proponent 
moves. The set of remaining, winning points is a greatest fixed-point, as classical 
for invariance during infinite time. 



4.2.1 Sequential Proponent Let S = {EB; MB'); cf. §4.1.4.c. 

Problem To derive winning guards Ci G V such that 

S^.P-P = S^.P'-'P, where = {MB^-, MB') and H^ = Uie/ C'* ^ H,. 

Solution Let C be the winning region S^.P'^P (§3.5.3): 
c S.P-C. 

The winning region C and the winning guards Ct are computed in the complete 
lattice 2^ by the following iterations, where Si = (EH^; MB'), i G I and n G IN : 

= P, cf = Si.P-C^''\ 
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Proof The iterates and have limits, by monotonicity: C 

and C C^"^. The limit of C*-"^ is the fixed point C because 

C(0) = P, = Ui67 S^.P-'C'^'^'^ = S.P'-'C^^K 

Since Be C B, we have Sf .P'~'P C .P'~'P. Given C = .P'~'P, the require- 

ment Sf .P^ P = S‘^.P'~'P is thus implied by C C Sf .P^ P. 

To prove the latter inclusion, let us verify that each S'°°-trajectory beginning 
in C = U.e/ Ci belongs to P P and does not terminate. For each i, given 
§4.1.4.b and the definition of we have Ci C {MBf, JEB').P'~'C . Thus, 

each point in Ci begins {Bi; B')-trajectories which all stay in P and reach some 
Cj C C again. Hence P is invariant and termination is excluded. Hence C = 
[j.^jC,cSf.P-P. 

4.2.2. Concurrent Proponent Assume S' ={{EiB\\JEB'); MB”) C[*](VixI^), 
where B = Gi ^ Bi is a, left branch, and Gi C IS x V 2 , Bi C [*]Vi, for 
i G I. 

Problem To derive winning global guards Ci C Vi x V2 such that 
S‘^.P'-P = Sf-P-P, 

where Sc = {{MBc\\MB'); MB”) and Be = Ui6/(C'i Gi) Bi. 

Solution As in §4.2.1, for Si = ((E(Gi ^ Bi)\\MB'); MB”). 

Proof Similar to the proof in §4.2.1. In particular: 

We have Ci C Gir]{{MBi\\MB'); MB”).P'~'C. Thus, each point in Ci begins 
{{Bi\\B'); H")-trajectories all of which stay in P and reach C again. Hence P is 
invariant and termination is excluded. 

4.3 Inevitability with Invariance 

A point is winning if it begins plays all of which stay in P and inevitably reach 
Q. Winning points are iteratively added to the initially empty domains of pro- 
ponent moves. The set of winning points is a least fixed-point, as classical for 
inevitability. 

4.3.1. Sequential Proponent Let S = (ER; MB). 

Problem To derive winning guards Ci G V such that 

SGP-Q = S*e.P-'Q, where Se = {MBe, MB') and Be = Ci B,. 

Solution Let C be such that Q U G is the winning region S*.P'~'Q (§3.5.2): 

G S.P-Q U S.P-C. 

The set G and the winning guards Ci are computed in the complete lattice 2^ 
by the following iterations, where Si = (EBi; MB'), i G I and n > 1 : 

Gf^ = S,.P-Q, g|”+^^ = G,^”^ U(S'*.P'^G(”))\G(”). 
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Proof Thanks to §4.1.4.b, we have Si = {JEBi; MB'). W.l.o.g., we assume Bi is 
not applicable in Q, viz. Bi = {—Q Bi). 

The iterates and have limits, by monotonicity (§3.5.2). The limit 
of is the fixed point C because 

= {}i^iS,.P-Q = S.P-Q, 

Cin+I) = (y ^(")) u U U,e/ Si.P-C^^\ 

Since Be C B, we have Sf.P'^'Q C S*.P'~'Q. Given Q U C = S*.P'^Q, the 
requirement Sf.P'~'Q = S* .P'~'Q is thus implied by Q U C C Sf.P'~'Q. 

To prove the latter inclusion, let us verify that each S'°°-trajectory beginning 
in C belongs to P"Q. Assume, for t G / and n > 1, 

Thus, U and C = The difference sets 

stratify C : for each x G C, there is a unique n such that x G because 

^(n) p ^(m) ^ 0 jf ^ ^ 

For all n > 1, each A^-trajectory beginning in is an S'"-trajectory 

which has a finite duration, stays in P and ends in Q. This property is verified 
by induction as follows. 

Basis: Let be any x G = Uie/ = [Ji^j Si.P'^Q. Hence each S°°- 
trajectory b beginning with x begins in and is an S§-trajectory, for some 
j G I; it is then an A^-trajectory by definition of Be- Since = Sj.P'^'Q, 
the A^-trajectory b has a finite duration, stays in P and ends in Q. No 
S'fc-trajectory continues b since B^ = {—Q Bk). 

Induction step: Assume the thesis holds for n. Then: 

Let be any x G = Uie/ Si.P'^C^'^K Hence each S°°- 

trajectory beginning with x has a prefix b\ which is an S§-trajectory for some 
j G I. Each such bi begins in C Cj and is thus an S'Ltrajectory. It 

has a finite duration, stays in P and ends with y G C^"^. Hence y G 
since a; ^ C(”). 

Given the induction hypothesis, each A^-trajectory beginning with y G 
is an A^-trajectory 6„ which has a finite duration, stays in P and ends in Q. 
By sequential composition of the S'^-trajectory bi and the S'”-trajectory bn, 
each S'°°-trajectory beginning with x G is an S'”+^-trajectory {bi; bn) 

which has a finite duration, stays in P and ends in Q. 

Thus, for each n > 1 and each x G D^'"\ x G S*.P^Q. Hence Q LI C = 

4.3.2. Concurrent Proponent We merely summarize the results; the details 
and proofs integrate §§ 4.2.2, 4.3.1. 
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Problem As in §4.2.2, using the requirement S*.P'~'Q = S*.P'~'Q. 
Solution As in §4.3.1, for Si = (E(Gi ^ Bi)\\JEB'); JEB"). 



4.3.3 Remarks 

Construction of a well-ordering The difference sets are well ordered by 

their rank n, and the latter is decremented by each S'c-trajectory. This ranking 
is related to value functions [Ba098, TLSOO] and to minimum time-to-reach 
functions [BCT02]. Value functions are defined by difference equations in the 
discrete-time case and by differential equations in the dense-time case. 

Consider classical synthesis methods for discrete-time games: iterations gen- 
erate a winning region, an explicit well-ordering is found for the latter, and a 
strategy function is then elaborated [GTW02 (§2.5.1), Tho95]. Here, iterations 
directly generate winning guards while the well-ordering appears only in the 
proof. Strategy functions are not used since strategies are represented by pro- 
cess guards; this representation depends on the finiteness of choice sets (§ 3.7). 

Simplification and deduction of winning guards If the considered game always 
begins in the winning region C, then each winning guard Ci can be simplified 
into C'i such that G' C G = G^. 

In Problem (I), the Cfs can be deduced from the winning region G by means 
of Ci = Si-P'^C. Here, the winning guards and the winning region are generated 
in a common iteration (§ 4.2). This illustrates the approach can be used uniformly 
for different properties of dynamics. 

Synthesis vs. analysis The coprocess S may happen to be correct, in the sense 
that the proponent EH may be replaced by MB^ viz. B^ = B. To verify S 
amounts thus to synthesize winning guards Ci such that {Ci Bf) = Bp, no 
restriction on H = IJjgj Hi is needed. This iterative verification is comparable 
to a model-checking procedure in the case it finds no errors [CGP99]. 

The present approach is also related to a method developed in the context 
of model checking [GhaOO]. The latter considers temporal- logic queries about 
finite-state, discrete-time systems, and presents a procedure for computing the 
answers. This may be used for specification improvement and system inspection. 

Non- deterministic strategies The proposed techniques generate winning guards 
which may well have non-empty intersections. It is thus possible to obtain non- 
deterministic winning strategies. 

Alternative complete strategies The iteration scheme in §4.3.1 is synchronous: it 
increments the rank n of each iterate G|"^ at each iteration step. This iteration 
scheme may well become asynchronous, provided it remains fair: some iterates 
may progress more slowly than other ones, but none is left out forever [Gou78, 
BerOO (Vol. II, §1.3.2)]. 
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The winning guards generated by asynchronous iterations determine alter- 
native winning strategies where moves may receive other priorities. These al- 
ternative strategies are complete because fair asynchronous iterations preserve 
the equality C = Uie/C'i- Complete, alternative strategies determine different 
coprocesses Sc- 

Liveness The liveness problem (§ 2.4.4.c) could be tackled by using nested fixed- 
points since = lyX : [S* X]; this is classical for finite-state 

games [BiiL69, Tho95]. Winning guards which ensure liveness would then be 
synthesized by nested iterations. 



Continuous-decision games If the strategic decisions in a game are continuous, 
then the time set is dense. In continuous-decision coprocesses, the closest se- 
quential decisions are separated by an infinitesimal time-interval. Accordingly, 
iterative techniques (§§ 3, 4) should be replaced by differential ones [Ba098, 
VinOO]. 



Discretizations Dense-time processes can be tackled by discrete-time sampling 
(§2.5.5), and time-to-reach functions for dense time can be computed through 
numerical discretization [BCT02] . Such discretizations may be organized in two 
levels: 

(i) The abstraction (or approximation) of dense-time processes by discrete-time 
ones results in small-step iterations (§2.5). 

(a) The abstraction of continuous-decision coprocesses by discrete-decision ones 
results in big-step iterations (§3.6). 

Discrete-time dynamics (i) induce discrete-decision interactions (ii), but not 
conversely: discrete-decision interactions in coprocesses may involve dense-time 
dynamics in processes. 



5 Discussions and Conclusions 



We briefly review related work on synthesis, summarize the present contribu- 
tions, discuss further work and conclude with a few observations. 



5.1 Related Work on Synthesis of Strategies 

For related work on discrete-decision coprocesses, see § 3.8. The two synthesis 
problems discussed here are defined in §4.1.2. Simple discrete-decision copro- 
cesses are considered in § 4. 1.4-Note. 1. We use R, R' for relational processes and 
B, B' for general ones. The proponent is Ei?. 
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Problem (I): Invariance without termination The classical solution for finite- 
state games is semi-iterative [BiiL69, TB70, RW89]: relational coprocesses 
(E_R; AR')^ are considered; winning regions are synthesized iteratively; winning- 
strategy functions are then extracted from these. Problem (I) is solved iteratively 
for the cooperative coprocesses (Ei?)“ [vLS79]. In [AMP95, MPS95, Tho95, 
BaW98, HenOO], it is solved by a semi-iterative method for systems on the form 
(Ei?; or (Ei?|| A similar approach is used in [AMP95, AsaOO, 

TLSOO] for hybrid systems like (Ei?; AB)^ or ((Ei?|| Ai?'); AB)“. 

For Problem (I), there is not much difference between iterative techniques 
and semi-iterative ones: the winning guards can be deduced from the winning 
region (§4.3.3) [AsaOO]. More significant problems, e.g. liveness, have been solved 
by semi-iterative methods [Tho95]; they are not treated in this paper. 

Problem (II): Inevitability with invariance Usually, the winning region of a finite- 
state game ((Ei?; Ai?')*, P"^(5) is generated iteratively, but not the winning 
strategy: each state is given a rank during the computation of the iterates, 
and the strategy function decreases this rank [BiiL69, TB70, MPS95, Tho95, 
BaW98j; see also §4.3.3. An iterative method is available for the cooperative 
coprocesses (EP)* [vLS79]. In [BKS98], the problem is solved by a systematic 
elimination of cycles in trajectories. In [HLMOI], control guards are derived it- 
eratively in an approach related to § 4.3. The algorithms elaborated in the latter 
two papers are respectively based on a graph model of discrete-event systems 
and on an automata model of hybrid systems. 

Regarding Problem (II), iterative techniques compare as follows with semi- 
iterative ones. The winning guards generated by iterations directly determine a 
winning strategy, whereas the explicit elaboration of a well-ordering and of an 
associated strategy-function is less immediate, especially in the case of infinite 
state-spaces. On the other hand, the proposed iterative techniques yield strate- 
gies which are equivalent to those obtained by semi-iterative methods, at least in 
the case of finite-state, discrete-time games and synchronous iterations (§4.3.3). 

Computations for dense-time dynamics Qualitative problems can be reduced 
to quantitative ones by using a binary set of quantities. Let us then look at 
optimization problems. 

Dense-time optimization problems can often be expressed by Hamilton- 
Jacobi(-Bellman) differential equations based on a dense-time form of Bellman’s 
principle of dynamic programming. These equations may be solved following 
Bellman’s principle, as precised in viscosity solutions, or Pontryagin’s princi- 
ple of optimality [BaC97, BerOO, VinOO, AgS02j. It could prove fruitful to use 
such methods for computing preconditions for dense-time processes, in particular 
when discontinuities render sampling inadequate. 

Similar observations apply to continuous-decision games. The max-min ver- 
sions of the optimization problems yield the Hamilton-Jacobi(-Bellman)-Isaacs 
equations [Isa65, Lew94, BaC97, Ba098]. These can be solved by max-min vari- 
ants of dense-time optimization methods. The iterative techniques used here 
present a similar structure (§4.3.3). In the case of continuous-decision games. 
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the differential equations assume properties such as lower semicontinuity; in the 
case of discrete-decision games, the iterations assume monotonicity properties. 



5.2 Contributions 

In the proposed framework, coprocesses integrate atomic moves with durative 
ones, discrete-time dynamics with dense-time ones, and dynamics with their 
selection modes. As to constructive design, iterative techniques serve to syn- 
thesize guards which ensure basic dynamical properties. These techniques are 
based on fixed points as also used in game analysis. Complete, finite-memory 
winning-strategies can thus be generated iteratively for discrete-decision games 
with finite choice-sets and dense- or discrete-time dynamics. 

The present results combine known ones, are not very original, treat limited 
problems so far, but may help to understand related approaches (§5.1). Note 
that a paper on the synthesis of correct guards for cooperative action-systems 
[vLS79] overlooks relevant previous work on the synthesis of winning strategies 
for noncooperative games [BiiL69, TB70]. 



5.3 Further Work 

Case studies A few examples were investigated while elaborating the framework 
and the synthesis techniques; they served both as guidelines and as test beds. 
Substantial case-studies should be developed too. They would foster a better 
grasp of the various approaches and improvements to methods of solution. 



Framework It could prove fruitful to define coprocesses and specifications on 
the basis of temporal y^-calculi and w-regular algebras [DNOO, GTW02]. More 
properties of coprocesses should be established. Preconditions for processes and 
coprocesses could be defined in terms of sets of cones for coprocesses; such sets 
should then be given a general definition, after the example in § 3.2.1. The com- 
putation of preconditions S.W should follow on an equal footing the structure 
of the coprocess S and that of the specification W . The relationships between 
discrete- and continuous-decision games should be analyzed thoroughly. 



Unification We use one model, viz. that of discrete-decision coprocesses, two 
properties, viz. safety and reachability, and two forms of coprocesses to be iter- 
ated, viz. the sequential and concurrent ones. This yields two fixed-point equa- 
tions and four solution techniques (§4), which have much in common. We may 
think of an integrated compositional method for a wider class of discrete-decision 
games. Other challenges exist: for instance, the use of stochastic processes; the 
unification and elaboration of analytical and computational methods for solving 
dense- and discrete-time problems efficiently; the synthesis of optimal strategies 
for quantitative games. 
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Time refinement The synthesis of winning moves is no less important than that 
of winning guards. The problem could be attacked by stepwise refinement as 
follows. Firstly, an abstract game is designed using a simple time-set. Secondly, 
a winning transform is synthesized. Thirdly, the winning transform is refined 
into a concrete game using a more detailed time-set. Process-based versions of 
refinement calculi should then be used [Lam94] . 

5.4 Conclusions 

Discrete-decision games are characterized by the discreteness of strategic deci- 
sions made by players. The difference between discrete- and dense-time dynamics 
for players is secondary. In processes, time domains should thus be definable to- 
gether with data domains. 

Iterative approaches prove helpful: fixed-point definitions exhibit essential 
patterns and iterations provide a clear basis for effective procedures. Iterative 
schemes abstract differential ones; they should thus be investigated together. 

Distinct frameworks are characterized by dense or discrete domains and by 
infinite or finite ones. Discrete-decision, finite-choice, dynamical games form just 
one class among many. This space should be explored systematically. 

It is good to verify systems. It is better to verify systems or else to exhibit 
errors, as in model checking. It is still better to verify systems or else to remove 
errors, as in correctness-improving transformations. This is especially true if the 
thinking effort and computing cost appear comparable for these three modes of 
reasoning in system design. 

Abstraction allows to analyze detailed, concrete systems in terms of simpler, 
qualitative ones [Bro03, CoCOO, HenOO]. However, abstraction amounts to reverse 
refinement, the discovery of good abstractions appears as difficult as that of good 
refinements, and the techniques often prove related. It seems thus reasonable to 
consider synthesis and stepwise refinement on a par with analysis and stepwise 
abstraction. 

The classical theory of interaction in systems is game theory. It is well-advised 
to take advantage of results in this field when developing models for cooperation 
and interaction. An example is the game-based approach for security problems. 
Clearly, the same holds wrt. control and optimization theory. 

Dynamics of various kinds take part in the interactions between computing 
systems and their environments. Computing science should thus cooperate with 
mathematical analysis as actively as with algebra and logic. This would help 
to establish a scientific basis which can be shared by software engineering and 
classical engineering. 
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Abstract. Inheritance and polymorphism are key mechanisms of the 
object-oriented approach that enable designers to develop systems in an 
incremental manner. In this paper, we develop techniques for reasoning 
incrementally about the behavior of such systems. A derived class de- 
signer will be able, using the proposed approach, to arrive at the richer 
behavior that polymorphic methods inherited from the base class will 
exhibit in the derived class, withont reanalyzing the code bodies of these 
methods. The approach is illustrated by applying it to a simple case 
study. 
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1 Introduction and Motivation 

Much of the power of the 00 approach derives from the key notions of in- 
heritance and polymorphism. Given an existing base class B, a designer can 
use inheritance to build a new derived class D that extends B. Some of the 
methods of B are redefined in D while others are inherited unchanged; some 
methods may be abstract, i.e., have no associated definition, in B, and defined 
in D. Polymorphism^ ensures that not just the methods redefined in D, but also 
other methods, these being the polymorphic methods, that invoke the redefined 
methods exhibit enriched behavior even though the polymorphic methods them- 
selves are inherited unchanged from B. Inheritance and polymorphism were two 
of Simula’s [DN66, DMN68] fundamental contributions that have revolutionized 
software design. But if we are to be able to exploit the full potential of inheritance 
and polymorphism, we must not only be able to build systems incrementally, but 
also to reason about their behavior incrementally. Our goal in this paper is to 
investigate the problems involved in such incremental reasoning and to develop 
techniques to address them. 

What information about the base class B does the designer of the derived 
class D need in order to reason incrementally about the behavior of D1 Suppose 

^ In this paper, by polymorphism we will mean the subtype polymorphism of [CW85], 
implemented using run-time dispatch in standard OO languages. 
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t{) is a method of B and that it invokes another method h{) of B, and suppose 
h{) is redefined in the derived class D. If t{) is applied to an object of type D, 
the h{) that will be invoked during this execution of t{) will be the one defined 
in D (rather than the one in B). In a sense, the polymorphic method provides 
the pattern, or template, of the calls to the methods that are intended to be 
redefined as needed in the derived class, while the template itself is inherited 
unchanged. It is for this reason that polymorphic methods are called template 
methods in the design patterns literature [GHJV95], the methods they invoke 
being called hook methods, and we will use this terminology in the rest of the 
paper. If B includes polymorphic methods^ such as t(), the designer of D not 
only needs to reason about the behavior of the methods she defines or redefines 
in D, but also about the modified behavior of the polymorphic methods of B 
resulting from redefinitions of methods that they invoke. One possibility would 
be for this designer to reanalyze the behavior of the body of t() appealing, during 
this reanalysis, to the modified behavior of the redefined methods. While this 
would work, it is clearly not an incremental approach. Thus the central question 
we are interested in is the following: 

What information should we include in the (base-class) specification of 
the template method so that a derived class designer can, in a sense, 
“plug-into” this specification, the behaviors of the hook methods as de- 
fined in the derived class, to arrive at the enriched behavior that the 
template method would exhibit (when applied to instances of the derived 
class), without having to reanalyze the body of the template method? 

Note that reanalysis of the template method bodies is not only undesirable, 
it may even be impossible if, for example, the template method is part of a base 
class that was purchased from a software vendor who, for proprietary reasons, 
did not provide access to the source code. 

We will see the full details of our answer to this question later, but the key 
is to include, in its specification, information about which hook methods t() 
invokes, the order it invokes them in, the arguments passed to the hook methods 
in these calls, etc. In order to provide this type of information, we will make use 
of a trace, denoted by the symbol r (or sometimes r*), to record the hook method 
calls that t{) makes. The specification of t(), in particular its post-condition, will 
give us information not only about the final values of the member variables when 
t{) finishes but also about the value of r, i.e., information about the identity of 
the hook methods t{) invoked during its execution, the values of the arguments 
it passed in these calls, etc. As we will see, the derived class designer can then 
plug into this specification, the behavior of the redefined hook methods to arrive 
at the corresponding new behavior of t(). 

^ In Simula and C++, h{) must have been flagged as virtual, else the h{) that is invoked 
during the execution of t{) would be the one defined in B. In languages like Java 
and Eiffel, all methods are virtual unless explicitly declared final. For concreteness, 
we occasionally use language-specific terminology but our approach is not language- 
specific. Note also that we use the terms ‘method’ and ‘function’ interchangeably. 
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There is one important requirement that these redefinitions must satisfy. 
Suppose that h{) is one of the hook methods t{) invokes. In arriving at the spec- 
ification of t{) by analyzing its code in the base class, we would have made some 
assumptions about the effects of the call(s) to h{) contained in the body of t{). 
Typically, these would correspond to the behaviors exhibited by h{) as defined 
in the base class and (presumably) specified in the base class specification of h{). 
Unless the redefinition of h{) in the derived class satisfies its base class specifi- 
cation, this analysis of t{) may no longer be valid, and we would be forced to 
reanalyze the body of t{). Since we want to avoid such reanalysis, we will require 
the redefinition of h{) in the derived class to satisfy its base class specification. 

Such a requirement is, in fact, not new to our work. It is the essential idea 
underlying the work on behavioral subtyping [Ame91, LW94, DL95]. Informally, 
a class A is a behavioral subtype^ of another class B if the behavior exhibited 
by objects that are instances of A is in some sense consistent with behaviors 
allowed by the specification of class B, in other words, if the methods of class A 
satisfy the specifications of the corresponding methods of B. If A is a behavioral 
subtype of B, then any reasoning that we may have performed on a piece of code 
that includes calls to methods of B will continue to be valid if these calls are 
instead dispatched to the corresponding methods defined in A since in any such 
reasoning, we could only have appealed to the specifications of the methods in B 
and the methods defined in A satisfy these specifications. In our case, we want 
to be sure that whatever conclusions we have arrived at about the behavior of 
the template method t{), on the basis of the base class specifications of the hook 
method h{), continue to be valid in the derived class, so we must require that 
the derived class definition of ft.() satisfy its base class specification. 

What is new about our work is that, if this requirement is satisfied, then 
the “plugging-in” process we outlined above will allow us to arrive at the richer 
behavior that t{) acquires as a result of the redefinition of h{). Thus our work 
is in a sense a key extension of the behavioral subtyping approach: behavioral 
subtyping ensures that what we have already concluded (from the analysis of 
t{) in the base class) continues to hold following the redefinition of the hook 
methods in the derived class; our work allows us to reason about the richer 
behavior of t{) resulting from this redefinition. Since the very raison d’etre of 
polymorphism is the ability to enrich the behavior of the polymorphic methods 
by suitable redefinitions of the hook methods, it is essential that the reasoning 
system enable us to reason about this enriched behavior. In Section 6, we will 
consider other related work in some detail. 



® Although from a formal point of view class and type are distinct notions, in most 
standard OO languages, as well as in much of standard OO practice, the two notions 
are identified. Hence in this paper we will use the two terms interchangeably. More 
importantly, we will only be interested in the notions of behavioral subtype/subclass 
based on the behaviors of the methods of the classes in question, not in syntactic 
notions of subtype/subclass based on the signatures of the methods. 




Incremental Reasoning for Object Oriented Systems 305 



The main contributions of this paper may be summarized as follows: 

— It identifies the key problems involved in specifying precisely the behavior 
of template methods and hook methods and in arriving at the derived-class 
behavior of a template method on the basis of its base class specification. 

— It develops an incremental reasoning technique to allow the base class de- 
signer to specify the behavior of the methods of her class, and to allow the 
derived class designer to plug-in information about the hook methods re- 
defined in the derived class into the bass-class-specifications of the template 
methods, to arrive at the derived-class behavior of these methods. 

— It illustrates the reasoning technique by applying it to a simple case study. 

The rest of the paper is organized as follows: In the next section, we introduce 
a simple 00 language fragment focused on polymorphism. In the third and 
fourth sections, we develop our incremental reasoning systems for specifying and 
verifying the behaviors of programs written in this language. The fifth section 
presents a simple case study to illustrate our reasoning technique. The sixth 
section summarizes related work. The seventh section reiterates the importance 
of an incremental reasoning system for dealing with polymorphism, summarizes 
our approach to such a system, and discusses possible extensions. 

2 Language and System Model 

The qualification of a method as virtual in Simula or C++, and the complemen- 
tary qualification of a method as final in Java or Eiffel, allow the compiler to 
determine whether or not run-time dispatching must be used in dealing with that 
method. For reasoning about the behavior of the methods, a more useful charac- 
terization is in terms of hook methods and template methods. Given that these 
notions were introduced in order to talk about the designs underlying particular 
00 systems, it should not be surprising that they are also useful in reasoning 
about the behavior of such systems. In this section we introduce a simple lan- 
guage notation and model that characterize methods in these terms; in the next 
two sections we will present our reasoning technique in terms of this model. The 
(partial) BNF grammar for our simple language appears in Figure 1; e in these 
productions denotes the empty string; note also that the symbols “{” and “}” 
that appear in the productions are terminal symbols (rather than extended BNF 
symbols indicating repetition of the enclosed constructs). 

The following points should be noted: 

1. A base class definition specifies the name of the class, the member variables 
of the class, the constructor function, and the methods of the class. A derived 
class definition, in addition to the above, also specifies the name of the class 
it inherits from; note that we consider only single inheritance. 

2. We assume that all member variables are protected, i.e., accessible to the 
derived class but not to client code; we also assume that all methods are 
public. Hence there are no keywords such as private or protected. 
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(class) 

(variables) 
(variable) 
(constructor) 
(methods) 
(method) 
(method kind) 



::= class (id) { (variables) (constructor) (methods) } 

I class (id) : (id) { (variables) (constructor) (methods) } 
::= e | (variable) (variables) 

;:= (simple type) (id)-, 

::= (id) ((parlist)) {(stmts)} 

::= e \ (method) (methods) 

::= (method kind) (id) ((parlist)) {(stmts)} 

::= h-method | t-method | ht-method | nht-method 



Fig. 1. (Partial) Grammar for simple 00 language 



3. Each class has a (single) constructor. The name of the constructor will, as 
usual, be the same as the name of the class. When an instance of a derived 
class is constructed, the base class constructor is executed first, then the 
derived class constructor. Classes do not have destructors. 

4. A method may be a hook method (h-method), a template method (t-method), 
a hook-template method (ht-method), or a non-hook-template method (nht- 
method). Run-time dispatching is done for h-methods and ht-methods but not 
for t-methods or nht-methods. h-methods and nht-methods may invoke only 
nht-methods; t-methods and ht-methods may invoke h-methods, ht-methods, 
and nht-methods. 

5. Only h-methods and ht-methods may be redefined in a derived class; t- and 
nht-methods must be inherited unchanged. When a method is redefined, no 
changes may be made in the number and types of parameters it expects. 

6. All member variables of a class are of simple types such as integer, boolean, 
etc. So an object will not contain references to other objects. The problem 
with allowing references to other objects is that this can lead to aliasing 
which presents some well-known problems when reasoning about behavior; 
since these problems are not directly related to inheritance and polymor- 
phism which is the focus of our work, we feel it is appropriate to eliminate 
aliasing from the picture. 

7. The parameters (other than the self object) to a method are of simple 
types and are all passed by- value-result. Here again allowing for passing 
by-reference could lead to aliasing which we wish to avoid. 

Our h- and ht-methods are like the virtual / non-final / non-frozen methods 
of Simula, C-h-h, Java or Eiffel respectively, while the t- and nht-methods are 
like non-virtual / final / frozen methods. Simula and C-h-h allow non- virtual 
methods to be redefined in the derived class but such redefinitions have no effect 
on base class (template) methods that invoke them; we could have similarly 
allowed our nht-methods to be redefined without this having an effect on the t- 
and ht-methods that invoke them; the changes in our reasoning technique to deal 
with this would be straightforward. Alternately, and more importantly, we could 
have treated all methods as ht-methods. While this would be general, it would 
also make the reasoning task unnecessarily complex since ht-methods are the 
most difficult to reason about. This is similar to a base class designer flagging 




Incremental Reasoning for Object Oriented Systems 307 



appropriate methods as final, rather than leaving, in the name of generality, every 
method open to redefinition in the derived classes. One point of terminology: 
henceforth, we will use the term ‘hook method’ to mean ‘h-method or ht-method’, 
since these are the two kinds of methods in our language that can be used to 
serve the role that hook methods are intended to serve; similarly, we will use 
‘template method’ to mean ‘t-method or ht-method’. 

Most 00 languages allow the hook methods to be abstract in the base class; 
indeed, in Simula, a method that is defined in the class cannot be flagged as vir- 
tual. For simplicity, we do not allow such methods in our language fragment but 
our reasoning technique can deal with such methods, as well as with Java-type 
interfaces where all the methods are abstract, in a natural manner. One other 
point worth noting is that a compiler for the language could easily ensure that 
the conditions on which types of methods may be invoked by a method of a given 
type are indeed satisfied (or, if not, produce appropriate error messages), and 
ensure, in the object code, that run-time dispatching is used for the appropriate 
types of methods; this is no different than a Simula or C++ compiler ensuring 
that run-time dispatching is used for virtual methods but not for non-virtual 
methods. 

We conclude this section with an Account class written in our language no- 
tation. This class, in Figure 2, will serve as the base class for our case study 
later in the paper where we will demonstrate the application of our reasoning 
technique. Account has a single member variable balance that maintains the cur- 
rent balance in the account; the derived classes we define later will introduce 
additional variables. The deposit() and withdraw() operations update balance in 
the expected manner; these are h-methods and will be redefined in the derived 
class(es) to provide richer behavior. The getlnfo() operation returns, as a string, 
the current balance in the account; note that string() returns the string repre- 
sentation of the value of its (integer) argument. getlnfo() is also an h-method and 
will be redefined in the derived class; in fact, it is via this redefinition that we 
will be able to see, so to speak, the enriched behaviors of the other operations. 
It is with an eye toward this redefinition that we have defined getlnfo() to return 
a result of type string (rather than int). 

The template method that will invoke these h-methods is processTransSeq(). 
This method will allow us (i.e., the client code) to process a sequence of trans- 
action requests, each request being for one of deposit, withdraw, or printinfo 
transactions. processTransSeq() has two string arguments, transs which will con- 
tain all the transaction requests, and results via which the method will return 
the result. processTransSeq() repeatedly reads the next transaction request from 
transs and processes it. In order to avoid getting involved with issues of string 
manipulation, we make use of a set of functions (whose definitions we omit) 
that allow us to extract individual transaction requests and conveniently ma- 
nipulate them; thus NextTrans(transs) is the first transaction in transs; Rest- 
Trans(transs) is the string consisting of all the remaining transactions (beyond 
the first one); TransName(nextReq), where nextReq is a single transaction re- 
quest, is the name of the transaction (“deposit”, “withdraw”, or “printinfo”); and 
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class Account { 

int balance; // current balance 



} 



Account(int b) { balance := b; } 

h-method deposit(int amt) { balance := balance + amt; } 
h-method withdraw(int amt) { balance := balance — amt; } 
h-method string getlnfo() { return string(balance); } 
t-method processTransSeq( string transs, string results) { 
results ;= {); 
while( transs 7^ () ) 

{ nextReq := NextTrans( transs ); transs := RestTrans( transs ); 
trans := TransName( nextReq ); amount := Amount( nextReq ); 
if( trans == "deposit" ) { deposit( amount ); } 
if( trans == "withdraw" ) { withdraw( amount ); } 
if( trans == "printinfo" ) { results -f= "<" ; 

results H-= getlnfo(); results -|-= ; } 



} 



} 



Fig. 2. Class Account 



Amount(nextReq), is the amount involved in the transaction (0 if the type of 
transaction is “getlnfo”)'^. 

If the next transaction requested is “deposit” or “withdraw”, processTransSeq() 
invokes the corresponding operation. If the transaction requested is “printinfo”, 
processTransSeqO calls getlnfo() and appends the returned result to results (en- 
closing this inside a pair of angle brackets, “j” and “i” to separate this result 
from the previous result in results); note that “-|-=” is the string append operator. 
This means that depending on the derived class design, when this transaction is 
processed, appropriate information about that particular type of account, as im- 
plemented in the (re-)definition of getlnfo() in the derived class, will be appended 
to results. The key reasoning questions are, what information do we include in 
the base class specification of processTransSeq(), and how, from this specification 
and the derived class behaviors of the h-methods, can the derived class designer 
arrive at this richer behavior of processTransSeq(), as exhibited in the value it 
returns in results? We will see the answers to these questions in the case study 
section. 



3 Reasoning About the Base Class 

Consider a base class B. The specification of B will consist of an invariant Ib 
and specifications for each of its methods. Ib, an assertion over the state, i.e., 

Good 00 design principles suggest that it would probably make sense to introduce an 
auxiliary class, Transaction, into which methods such as NextTrans() can be collected 
but in the interest of space, we will not do so. Note also that we have omitted the 
declarations of local variables, nextReq, trans, and amount, in processTransSeq(). 
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the member variables of B, will be satisfied at the start and end of execution 
of each method. Next, consider the various kinds of methods. Suppose n() is an 
nht-method. Its specification will be of the usual form: 

{pre.n{),post.n{)) (1) 

where the pre-condition pre.n{) is an assertion over the state, and the parame- 
ters passed to n{) at the time that n{) starts execution, and the post-condition 
post.n{) is an assertion over the state and the parameters to n() at the time it 
starts execution and at the time it finishes execution. In the post-condition, we 
will use the OCL [WK99] notation x@pre to refer to the value of the variable x 
at the time n() starts, and x to refer to its value when n() finishes execution. 

The specification of h-methods is similar. The difference between these two 
types of methods will show up when we consider derived classes in the next 
section. For nht-methods, we will essentially inherit the specification from the 
base class since these methods cannot be redefined in the derived class; for h- 
methods, we will either inherit the base class specification if the method is not 
redefined, or come up with an appropriate new specification if the method is 
redefined. 

Next consider a t-method t{). We will associate two specifications with t{). 
The first, its functional- or f- specification, will be similar to (1) and will specify 
the effect of of t{) on member variables of B and the parameters of t{). The 
second, its enrichment- or e-specifieation, will be for use by the derived class 
designer and will include information about invocations of hook methods. We will 
use r, the trace (or sequence), to record this information, and the e-specification 
will give us information about the value of r: 

F-specification: {pre.t{),vbpost.t{)) 

E-specification: {epre.tif), epost.t{)) (2) 

At its start, t() has not yet invoked any h- methods so r at that point will 
be the empty sequence £. epost.tf) will give us information about the values of 
the member variables of B, of t()’s parameters, and of course about the value 
of T when t{) finishes execution. Thus the relation that must hold between the 
assertions of the f- and e-specifications is as follows: 

epre.tf) = {pre.t{) A (r = e)) 

epost.tQ post.tQ (3) 

What information concerning calls to hook methods (i.e., h- and ht- methods) 
that t{) makes should we include in t? A few examples will help us answer this 
question. Suppose B consists of just two methods, t{) and an h-method hl{). 
Suppose hl{), as defined in B, makes no changes to the values of any of the 
member variables of B. Suppose in a derived class D we introduce a new (integer) 
variable i and redefine hl{) to increment i by 1 (and leave the other member 
variables, inherited from B, unchanged). If t{) is applied to an instance of D, 
during this execution of t{), calls to hl{) will be dispatched to the one defined in 
D, and hence this call to t{) will increment i (which is a component of the object 
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t{) is applied to since this object is an instance of D) by an amount equal to the 
number of times t{) invokes In order to enable the derived class designer 
to arrive at the value that i will be incremented by during such an execution of 
t{) without reanalyzing the body oft{), the base class specification of t{) would 
therefore have to include information about how many times t() invokes hook 
methods. 

It is easy to see that this alone is not sufficient in general. Suppose in this 
example that there were two h-methods hl{) and h2{), and that t{) invokes each 
of them several times. Suppose /il() is redefined in D to increment i by 1 as 
before, and h2{) is redefined to increment i by 2. Then, in order to know what 
effect an execution of t{) (applied to an instance of D) will have on i, we need 
to know how many times t{) invokes /il() and how many times it invokes h2{), 
rather than just the combined total of the two. But this is also insufficient in 
general. Suppose that two variables i, j are introduced in D and that while hlQ, 
as before, increments t by 1 each time it is invoked, h2() does not change i but 
increments j by the current value of i, i.e., the value that i had at the time of 
this invocation of h2{). Then the effect that an execution of t{) has on j will 
depend not only on how many times and h2{) are invoked but also on how 
these invocations are interleaved] for example, if t{) were to invoke twice 
and h2{) once during its execution, then during this execution the value of j 
would increase by i@pre, or i@pre+ 1, or i@pre + 2, where as noted earlier i@pre 
denotes the value of i at the start of this execution of t(), depending respectively 
on whether t{) invokes h2{) before calling hl{), or after the first call to hl{), or 
after the second call to hl{). 

Hence we need to be able to provide information about the order of the calls 
t{) makes to the hook methods. This is still insufficient. Suppose, we revise the 
example so that h2{) (as defined in D) increments j not by i but by {i + k) 
where fc is a member variable of B. Now it is quite possible that t{) has changed 
the value of k before calling h2{) and that it will change it further once the call 
from h2{) returns. In this case, to arrive at the effect that t{) will have on j 
without reanalyzing its body, we will need to know what value t{) has left in k 
immediately before the call to h2{). In general, we would need to know the entire 
‘state’, i.e., the values of all member variables of B, before each call t{) makes 
to a hook method, and this information will have to be recorded in r. It turns 
out that we also need to record the state immediately following the return from 
each call to a hook method; this is because it is possible that the hook method 
might, according to its specification, assign one of two different values to one of 
the member variables (of B) and what t{) does following the return from the 
hook method, including what other hook methods it calls, might depend on this 
value; so in order to be able to relate the values in these variables to what these 
later calls might do (including, in particular, assigning values to other member 
variables, some of which might be introduced in the derived class), we need to 
record in r the state following each hook method call. Finally, if the hook method 
receives any additional parameters, we also need to record the values of these 
arguments and the results returned by the hook method since, as in the case of 
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the values of member variables of B, what t{) does following the return will, in 
general, depend on these results. 

To record all this information, we will use the following structure for the 
sequence r. Each element of r will represent one call to a hook method and 
the corresponding return. As noted earlier, at the start of the execution of t(), 
r will be the empty sequence s. Suppose at some point in this execution the 
current state, i.e., the values of all member variables of B, is a' , and t{) invokes 
an h-method h{), the values of the additional arguments passed to h{) being Wi'; 
and suppose that the state when h{) returns is a, and the result values of the 
additional parameters are Ha. Then this call-return will be recorded in t as the 
element: 

(h, a', Tla! , a, aa) (4) 

If h{) were an ht- rather than an h-method, we would again record the same 
information in r about a call from t{) to h{). Note that in this case, during its 
execution, h{) may in turn invoke another h-method (or ht-method), call it g{). 
Although this call to g{) did arise as a result of the original call that t{) made to 
h{), the call to g{) will not be recorded in the trace of t{) (it will, of course, be 
recorded in the trace of h{)). If g{) were to be redefined in the derived class, the 
derived class designer would be able, as we will see in detail in the next section, 
to arrive incrementally at the resulting enriched behavior of h{) on the basis of 
the e-specification of h{) (and the information that specification provides about 
the calls to g{) that h{) makes), and then arrive at the enriched behavior of t{) 
on the basis of the e-specification of t{) and the information it provides about 
the calls that t{) makes to h{). Thus the enrichment in the behavior of t{) arises 
because of the enrichment in the behavior of h{); whether that latter enrichment 
is due to a redefinition of h{) in the derived class or due to a redefinition of 
an h-method that h{) invokes is not relevant when reasoning about the enriched 
behavior of t(). In other words, the functioning of t() depends only on what the 
call to h{) does and what enrichment is done to this behavior of /i(), not how 
that enrichment is achieved, so we only need record the call to /i() in the trace 
of t{), not the calls to h-methods that h{) in turn may make. 

So much for the structure of t. In what form should information about t be 
included in epost.t{), the e-post-condition of t()? One extreme approach would be 
to explicitly list, in epost.t{), all the possible values r could have when t{) finishes, 
i.e., list all the different sequences of hook method calls that t{) could have 
gone through during its execution, and for each, provide complete information 
about each component of each element of r. While this would work, doing it 
naively would generally be far too tedious. A better approach is to define suitable 
functions, the details of which may depend on the particular application, on r, 
and write the specification in terms of these functions; we will see in our case 
study. 

Further, it is usually not necessary to provide complete information about 
T. This depends in part upon the kind of enrichments the base class designer 
expects will be made in the derived classes. If, for example, in the case of the 
Account class defined in the last section, we do not expect the hook methods 
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to be redefined in such a way as to depend on the value of balance at the time 
that the hook method is invoked, then there is no need to include information 
about this in specifying the t-method processTransSeq(). On the flip-side, if the 
derived class designer does redefine a hook method in such a way that its enriched 
behavior critically depends on the value of balance, she would be unable to reason 
incrementally about the corresponding enriched behavior of processTransSeq(). 
We will return to this point later. 

How do we show that t{) meets its specifications? The main problem has to 
do with showing that the body of t{) meets its e-specification because once we 
do that, we simply need to check that the relation specified in (3) holds in order 
to conclude that t{) meets its f-specification as well. When reasoning about 
the body of t(), we use standard axioms and rules for dealing with standard 
statements such as assignment and if- else. The one statement for which we need 
a new rule is call to h-method (or ht-method), to account for recording on r, 
information about the call. 

Rl. h/ht- Method Call 

p ^ {h A pre.h{x)[x <— oa]) 

\{3a' ,1 w!).[p[t ^ ablij), o ^ o' ,1m ^ oo'] 

A post.h{x)\o @pre <— o' , x@pre <— Ha' , x <— oo] A h 
A last{T) = {h, o' ,lw! , o,lm) ] ] q 



{p} h{aa); { g } 



h{) is the method being called, ad being the (additional) arguments for this 
call. The first antecedent of Rl requires us to show that if the assertion p which 
is the pre-condition of the call is satisfied, then /{,, the invariant of B is satisfied; 
and the pre-condition pre.h{) of the (f-)specification of the method^ is satisfied 
with the actual arguments (oa) substituting for the formal parameters (S); ” 

denotes (simultaneous) substitution of all occurrences, in the given assertion, of 
the variable(s) on the left side of the by the expression(s) on the right. 
The second antecedent requires us to show that we have added a new element 
to r corresponding to this call and that the state at this point (and the returned 
values of the arguments) satisfy the post-condition of the call to h{). last{T), as 
the name suggests, is the last, i.e. the rightmost, element of r; abl{r) stands for 
“all but the last element ofr” and is the sequence obtained from t by omitting 
its last element. In more detail, in this antecedent, a' denotes the state that 
existed immediately before the call to h{) and dd! the values of the arguments 
at that point; so this antecedent requires us to show that: if the state (and 
argument values) that existed immediately before the call and the trace, less 

® If h{) is an ht-method, it will have, as we will see shortly, both an f- and an e- 
specification in the same manner as t-methods. But as far as t{) is concerned, only 
the functional effect of h{) is relevant; thus the pre- and post- assertions referred to 
in the antecedents of Rl are from h{)’s f-specification. 
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its last element, satisfy the assertion that is the pre-condition of the call; and 
if the post-condition of the f-specification of h{) is satisfied with appropriate 
substitutions for the before- and after-states and argument values; and if the 
class invariant is satisfied; and if the (newly added) last element of r consists of 
the name of the called method (h), the state {a') immediately before the call, the 
initial value {Ho!) of the arguments, the state {a) immediately after the return 
from h, and the final values of the arguments (oa); Then it must be the case 
that the specified post-condition q of this call to h{) is also satisfied. If these 
two antecedents can be shown then, by appealing to the rule, we may derive the 
specified conclusion. 

Although the rule looks rather involved, the complexity is mostly notational. 
It just captures the fact that the effect of the call to h{) is to modify the values 
of the member variables of B and the arguments passed to h{) as specified in 
the (functional) post-condition of h{), and to append an appropriate element to 
r to represent the call/return. In practice, in reasoning about the body of t{), 
we encounter such a call we would typically simply write appropriate pre- and 
post-conditions for the call statement and check semi-formally that what these 
assertions say about the changes in the values of the member variables of B, the 
values of the arguments to h{), and the value of r, are consistent with what the 
f-specification of h{) says will be the effect of the method on the members of B 
and the parameters to h{), and with recording this call/return on t. 

The final type of method is the ht-method. Suppose ht{) is such a method. Its 
specification will be similar to that of a t-method. In other words, ht{) will have 
f- and e-specifications. The former specifies the effect of an execution of ht{) on 
the member variables of B and the parameters of ht{), and the latter provides 
information also about the calls that ht{) makes to hook methods during its 
execution. The key difference with t-methods will show up when we consider 
derived classes. For t-methods, we will use the e-specification from the base class 
and arrive at its enriched behavior (and the corresponding f-specification) by 
appealing to the richer behavior of the hook methods it invokes. We will do the 
same also for ht-methods that are inherited unchanged from the base class. But if 
an ht-method is redefined in the derived class, we will come up with appropriate 
new f- and e-specifications. 

Let us now briefly turn to invariants. In our system, when reasoning about 
the base class B, we use a standard approach to dealing with invariants. In other 
words, for each method /(), the result we establish for S, the body of /() is: 

{hApre.fO} S {IbApost.fO} (5) 

where If, is the invariant for B. Further, when establishing this result, for dealing 
with calls in S to other methods (either nht-methods or hook methods) of B, we 
must check that not only is the pre-condition of the method being called satisfied 
but also the invariant; and, conversely, we may assume, when the method call 
returns, that not only will the method’s post-condition be satisfied but also the 
invariant. Any functions redefined in a derived class D of B will also have to 
maintain this invariant (since otherwise, if /() were a t-method and one of the 
calls in S is dispatched to such a redefined method, the assumption made in 
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establishing (5) that h will hold when this call returns will no longer be valid); 
we will formalize this requirement in the next section. One type of method we 
have not considered so far is constructors. Clearly, we must check that each 
constructor c() of B is such that when it finishes execution, It, is satisfied. The 
final step in reasoning about B is to ensure that it meets its abstract specification, 
intended for use by clients of B. This can be done in a standard fashion, see for 
example [Jon90]; inheritance and polymorphism do not add any complexity to 
these issues, so we will not discuss them further. 

We conclude this section with a comment about our trace r. r is like an 
auxiliary variable of Owicki and Cries [OG76], but there are some differences. 
In systems such as those of [OG76], we are allowed, when reasoning about the 
behavior of a piece of code, to introduce as many auxiliary variables of whatever 
types as we wish; we also have to introduce suitable assignment statements (into 
the code whose behavior we are reasoning about) to update the values of the 
auxiliary variables at appropriate points as we wish. By contrast, in our system, 
r is the only additional variable; its structure is fixed, as specified in (4); the 
updates to r take place automatically with each call that t{) makes to a hook 
method; this is represented in our system by the rule Rl. Note also that r is 
not a member variable of the class; it only records the calls that this method 
t{) makes to h- and ht- methods during one particular execution; thus, r is 
like a local variable of t{), initialized, as specified in (3), to e at the start of 
this execution. Its purpose is not so much to help reason about the behavior 
of the base class B as to provide more information in the e-specification of t{) 
than can be provided using just the member variables of B. And the purpose of 
providing this extra information is to enable us to arrive at the richer behavior 
of t() that results from redefinitions, in a derived class of B, of one or more of 
the methods that t{) invokes, without having to reanalyze the body of t{). Thus 
while Owicki-Gries type auxiliary variables are introduced to help in reasoning 
about the behavior of the piece of code under consideration, we have introduced 
T to help the derived class designer to reason incrementally about the behavior 
of her derived class. 

4 Incremental Reasoning About the Derived Class 

Let D he a derived class of B. In our skeletal language, as in most standard 
00 languages, the designer of D may introduce new member variables in D, 
define entirely new methods, or redefine hook methods inherited from the base 
class; nht-methods and t-methods must be inherited unchanged. For methods 
that are newly defined in D, we use the same approach as in B. From the point 
of view of incremental reasoning, the key question is how to arrive at the richer 
behavior of inherited template methods without reanalyzing the body of the 
template method. This question will be the main focus of this section but we 
start our discussion with the relation between the invariants for B and D and 
then consider ways to reason about each type of method. 
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Let h, Id be the invariants for _B, D. Since some of the methods will be 
inherited unchanged from B, and since these methods require Ib to be satisfied 
before they start execution, we will require the following: 

Id Ib ( 6 ) 

And in order to ensure that each method in D, including the inherited ones, leave 
Id satisfied when they finish execution, we will have to impose further conditions 
on the specifications for the individual methods as we will see below. (6) will be 
part of the behavioral subclassing relation to be defined shortly. 

Suppose n() is an nht-method inherited from B. The (concrete) specification 
of n(), as a method of D, will be in terms of the overall state, i.e., the values of the 
member variables defined in D as well as those inherited from B. For convenience, 
in our discussion below, we will use a to denote the overall state, alb to denote 
the portion of the state inherited from B, and aid the portion defined in D. 
Let {pre.B.n{),post.B.n{)) be the specification of n() in the base class B. Since 
the method is inherited unchanged by D, execution of n() cannot change the 
value of any variable introduced in D, i.e., the value of a Id when n() finishes 
execution will be the same as when it started. Hence, {pre.D ,n{) , post.D ,n{)) , the 
specification of n() in D, follows from its base class specification if the following 
conditions are satisfied: 

{pre.D.n{) A Id) pre.B.n{) 

{post.B.n{) A Ib A {pre.D.nQ A /d)[cr ^ a@pre] A{a Id = ald@pre)) 

^ {post.D.n{) A Id) (7) 

If pre.D.n{) is satisfied when n() is invoked, the relation between the pre- 
conditions ensures that pre.B.n{) will be satisfied at that point. Hence, given 
that we have checked (when reasoning about the base class) that the body of 
n() satisfies its base class specification, the assertion post. B. nil) h) ^bl be 

satisfied when n() finishes execution. In addition, the clause (aid = ald@pre) 
which is essentially an abbreviation for a set of clauses that assert, for each 
member variable introduced in D, that its value is unchanged from its value 
at the start of n(), will also be satisfied since these variables are unaffected by 
n(). The clause (pre.D.n() A Id)[o' ^ a@pre] asserts that the state, including 
the values of the variables introduced in D, at the time n() started execution 
satisfies the (new) pre-condition and invariant. Note that pre.D.n() may include 
conditions on the values of the variables introduced in D. In that case, the as- 
sertion (a I d = cr J, d@pre) will allow us to carry these conditions forward to 
post.D.n(). This may be of help in showing, as required by (7), that Id will hold 
at that point. 

Next consider h(), an h-method. If h() is inherited unchanged, we treat it in 
the same way as an nht-method. If h() is redefined in D, the derived class designer 
will have to come up with a new specification, (pre.D.h(), post.D.h()), and check 
(or formally verify) that the redefined method satisfies this specification (as well 
as Id, as required by (5)). In either case, we also need to impose a requirement 
of behavioral consistency with the base class specification {pre.B.h(),post.B.h()) 
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of h{) since otherwise any reasoning that we have done (concerning the behavior 
template methods that invoke h{)) on the basis of that specification may no 
longer be valid. 

Definition: The derived class £> is a behavioral subclass of its base class B if 
the following conditions are satisfied: 

Id h 

If /i() is an h-method or an ht-method, then 
{pre.B.hO A h) ^ {pre.D.h{) A Id) 

{post.D ,h{) A Id) post.B.h{) (8) 

We require, as part of our reasoning system, that D be a behavioral subclass^ 
of B. 

Consider a call to h{) in a t-method, t{). In D, this call will be dispatched to 
the h{) defined in D; so when the call returns, {post.D.hQ A Id) will be satisfied 
and hence, by the relation between post-conditions and invariants required by 
(8), so will {post.B.h{) A h) which is what we must have assumed when rea- 
soning about t{) in the base class. Thus behavioral subclassing ensures that the 
reasoning we have performed in the base class about a method that calls h{) 
continues to be valid although h{) has been redefined in the derived class. Note 
also that in order for post.D.hQ to be satisfied when D.h{) finishes execution, 
(pre.D.h{) A Id) must have been satisfied at the time of the call to /i(); the 
relation required by (8) between the pre-conditions and invariants, given that 
when reasoning in the base class about the calls in t{) to h{) we must have 
checked that (pre.B.h{) A h) is satisfied immediately prior to each of these calls, 
ensures this. It is worth noting that (8) imposes severe constraints on the de- 
rived class. In particular, the relation that (8) requires between the base class 
pre-condition & invariant and the derived class pre-condition & invariant means 
that the derived-class pre-condition of h{) cannot impose any requirements on 
the values of member variables that may be introduced in D. Nevertheless, by 
using the @pre notation to refer to the values of variables at the start of hi), we 
will be able, in post.D.h{), to specify how D.h{) changes the values of variables 
introduced in D; and the rule R2 will allow us to appeal to this information to 
arrive at the effect that t{) has on these variables. In more detail, we will look 
at each element in the trace r of t{), and add, to the base-class specification of 
t{), the assertion that the states and argument values recorded in this particular 
element of r satisfies the derived class post-condition of the h-method invoked. 
Suppose the element of t is {h, crl, ool, ct2, ao2), then: 

a. We can assert post.D.h{) with crl and a2 playing the roles respectively of the 
state immediately before the call and the state immediately after the call, 
and lial and lia2 being the argument values before and after the call. 

® (8) is very similar to behavioral subtyping [LW93, LW94]; nevertheless we use a 
different term since behavioral subtyping is a relation that involves the abstract 
specifications of two classes while ours is a relation between the concrete specifica- 
tions of a base class and its derived class. 
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b. We can assert that the H-portion of the state can change only due to calls 
to h/ht-methods since t{) was defined as part of the base class so its code 
cannot refer to this portion of the state. Thus if ap is the ‘final state’ of the 
previous element of r, i.e., is the fourth component of the {k— 1)*^ element of 
r, then we must have {apld = crlld); similarly if an is the ‘initial state’ of 
the next element of r, i.e., is the second component of the (fc + 1)'** element 
of T, then {a2ld = an id). 

Rule R2 below formalizes these ideas. The following functions and predicates 
on traces, trace elements and their components, etc., will be useful in expressing 
this formalization: 

|r|: Length of r, i.e., number of elements in r. 
r[fc]: The element of r. 

T[k].hm: The identity of the hook method called in the element of r. 
T[k].is: The initial state, i.e., the state just before this call. 
r[k].fs: The final state, i.e., the state just after the method returns. 

T[k].ia: The values of the arguments passed in this call. 

T[k].fa: The values of the arguments when the method returns. 
rib: Same as r except that in each ‘state’ component of each element of r, we 
only retain the base-class portion of the state; similarly r J, d is obtained 
from T by retaining, in each ‘state’ component of each element of r, only the 
portion of the state introduced in the derived class. Naturally, J, b and J, d 
operations are applicable only to traces at the derived class level. 
ncbc{ai,T,af): ncbc{) denotes “no change between calls”; i.e., the H-portion 
of the state does not change between calls to hook methods, ai is the initial 
state, i.e., the state at the start of t(), and af the final state, i.e., the state 
at the end of t(). More formally: 
ncbc{ai, r, af) = 

((|r| = 0) ^ {aild= af Id)) 

A ((|r| > 0) ^ {{aild= r[l].zsj,d) A {afld = T[|r|]./sJ,d) A 

(Vj : (1 < J < |r|) :: {T[j].fs Id = r[j + l].zsid)))) 

Since ai is the state that t{) starts in, the id portion of the state just before 
the first call recorded in r will be same as the aiid since the portion of t{) 
that precedes this call cannot have modified it. Similarly, the Id portion of 
the state when t{) finishes execution will be same as the J, d portion of the 
state immediately after the last call recorded in r. This explains the first 
two clauses in the case that (|r| > 0). The third clause states that the | d 
portion of the ‘initial state’ recorded in the (j + 1)'** call is the same as the 
J,d of the ‘final state’ recorded in the call. If (|r| = 0), the id portion of 
the final state when t{) finishes is the same as J, d of the state at the start of 
t{) since no hook methods are invoked. 
ccds{T,k): ccds{) denotes “change (in state) recorded in the k*^ element of r 

is consistent with derived-class specification (of the hook method)”; i.e., the 
states and argument values recorded in the k*^ element of t is consistent 
with the f-specification, in the derived class, of the hook method invoked in 
this element. More formally: 
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ccds{T, k) = {post.D .T[k].hm{)[xx@pre ^ T[k].ia, a@pre ^ T[k].is, 

XX ^ r[fc] .fa, a ^ T[k] .fs] 

A I d[<J ^ T[k].fs]) 

ccdsQ asserts that the initial and final values of the arguments and initial 
and final states recorded in r[fc] satisfy the conditions that the derived class 
f-post-condition imposes on the initial and final values of its parameters 
and the initial and final states when the method begins and ends. This is 
what will allow us to arrive at the richer behavior of t() by appealing to 
the richer behavior of the redefined T[k].hm as expressed in its derived class 
f-post-condition . 

With these preliminaries out of the way, we can present the main rule R2 that 
makes it possible to reason incrementally in our system. The rule requires us 



R2. Enrichment Rule 

[epre.D.tQ A Id) => epre.B.tQ 

[epost.B.t{)[T <— rib, a ^ o [h, a@pre<^ a@preib] 

A [pre.D.tQ A Id)['x ^ a@pre] 

A ncbc{a@pre,T,a) A (Vfc : (1 < fc < |r|) ccds(r, fc))] => (Id A epost.D.tQ) 



{epre.D.tQ, epost.D.tQ) 



to establish the specified antecedents in order to conclude the derived-class e- 
specification for t(). The first antecedent requires us to show that if a state 
satisfies the derived-class pre-condition of t{), it also satisfies the base-class pre- 
condition. This is needed because when reasoning, in the base class, about what 
t{) does when it starts, we had assumed that the state satisfies the base-class 
pre-condition; so unless this is true, that reasoning may no longer be valid. In 
the base class reasoning, we also assumed that the initial state satisfies Is', this 
will still be the case because in the derived class we may assume that the state 
will satisfy Id at the start of t{), and hence, given the requirement of behavioral 
subclassing, the state will also satisfy h. 

In the second antecedent, a@pre and a denote the complete (i.e., both base- 
and derived-class portions) initial and final states when t{) begins and ends 
execution. Since epost.B.tQ refers only to the base class portion of the state, we 
replace a and a@pre in epost.B.tQ) by the J, b portion of these states. Similarly, we 
replace r in epost.B.tQ) by rib. In practice, these substitutions tend to require 
no real effort. Thus, for example, suppose x is a member variable of B and that 
epost.B.tQ) contains a clause {x = x@pre + 10); since a; is a component of both 
a and aQb (and x@pre a component of a@pre and a@prelb), nothing needs to 
be done, as far as this clause is concerned, to effect the substitutions. We will 
see this in practice in the case study later in the paper. 

Thus this antecedent requires us, given the base class e-post-condition of t{), 
given that the derived class portion of the state doesn’t change between calls to 
hook methods, and given that following each call recorded on r, the state and 
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argument values satisfy the derived class post-condition of the method called, 
to show that the derived-class invariant and the derived class e-post-condition 
of t{) are satisfied. As explained earlier, it is the assumption that the state and 
argument values following calls to the h/ht-methods satisfy the richer derived 
class specification of these methods, that allows us to arrive at a correspondingly 
richer post-condition epost.D.t{) for t{) without having to re-analyze its body. 

It maybe useful to summarize our approach for reasoning about the derived 
class D-. We first come up with the invariant Id for the class, the e-specification 
and f-specification for each t-method and each ht-method of the class, and the 
specification for each h-method and each nht-method. Next we check that D is 
a behavioral subclass of B, i.e., the requirements specified in (8) are satisfied. 
Next, we have to verify that each method satisfies its specification(s). For each 
method that is newly defined or is redefined in D, we use the same approach 
as in the base class; for the redefined methods, we also check (or have checked) 
that the relation, imposed by the behavioural subclassing requirement, between 
the method’s derived class specification and its base class specification. For non- 
template methods inherited from the base class, as we saw in (7), the specification 
is the same as in the base class with the addition, in the post-condition of the 
method, that the method does not change the values of member variables newly 
introduced in D. For template methods, and this is the focus of our paper, 
we use the rule R2 to (arrive at and) justify the richer e-specification for the 
method, and in turn use this richer e-specification to justify a correspondingly 
richer f-specification (as required by (3)). 

One point is worth stressing: if h{) is an ht-method that is redefined in D, the 
behavioral subclassing requirement has to do with its f-specification, not its e- 
specification. This is because, so long as the (functional) behavior of the redefined 
h{) is consistent with its base class f-specification, the reasoning that we have 
done in the base class about the behavior of any (template) methods that invoke 
h{) will remain valid. The point is that the e-specification for h{) in the base 
class would have allowed us to arrive (using rule R2) at its richer behavior if 
we had inherited h{) unchanged but had redefined some of the hook methods it 
invokes; if instead we redefine h{) in D, then its base class e-specification is of 
no particular relevance in the derived class. 

One important question that any axiomatic system has to address is that of 
soundness and (relative) completeness with respect to the operational model of 
the programming language/system. Because of space limitations, we will con- 
sider this question only briefly. The main question concerns the behavior of 
template methods since our approach to the other methods is standard. And 
here, one problem in establishing soundness and completeness of our system is 
that the trace r that plays a central role in our axiomatic system is not part of 
standard operational models of 00 languages; as a result, we cannot talk about 
the validity of our e-specifications with respect to our model. 

This may seem an advantage since we would then have to worry only about 
the f-specifications. But the problem is that in our approach, we first establish 
the e-specification (with rules Rl, R2 being the key ones for dealing with the 
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trace information), and then establish the f-specification by showing that the 
conditions specified in (3) are satisfied. Hence we cannot establish the validity 
of an f-specification without first showing the validity of the e-specification that 
the f-specification is based on. The solution is to introduce traces also into the 
operational model^. As in the axiomatic system, the trace in the model would 
record calls to and returns from hook methods; each such call-return would 
record the name of the method called, the argument values and state at the 
time of the call, and the argument values and state at the time of the return. 
With this change, it is straightforward to show that results established using our 
reasoning system in particular using rule Rl, about a base class are valid in the 
model. 

Results about a derived class, in particular those established using R2, are 
more difficult. One possible approach would be as follows: Consider the proof 
outline (in the base class) that established the original e-specification of the 
template method in question. Treat the method as a member of the derived 
class and develop a new proof outline; this new outline is obtained by adding, 
to each assertion in the original proof outline, the clauses ncbc{) and ccdsQ (for 
all k < |r|). These clauses must hold at all points in this method (considered 
as a member of the derived class) for the same reason as before, that is, the 
member variables introduced in the derived class can change only due to the 
calls to the hook methods. Thus this new proof outline justifies the enriched 
e-post-condition that appears in R2, and hence shows that any result derived 
by using that rule® must be valid in the model. 

So much for soundness. Now consider (relative) completeness. To show com- 
pleteness, we have to show that the strongest post-condition for any method, i.e., 
the assertion that is satisfied only by states that can operationally arise when 
method finishes execution, can be established. Here again the argument is best 
presented in terms of proof outlines. Consider the base class. For each statement 
in the method, we simply use the strongest post-condition corresponding to the 
statement and its pre-condition. Then we can inductively argue that the result- 
ing post-condition is indeed the strongest possible one for the entire method. 
Consider now a template method and its proof outline in the base class. From 
this, derive a new proof outline for the method in the derived class by adding 
the ncbc{) and ccds{) (for all k < |r|) clauses as before to each assertion in the 
base-class proof outline. Again we can argue inductively that the assertion spec- 
ified in this proof outline at each point in the method is indeed the strongest 
possible assertion at that point; and hence that, using R2, we will be able to 

^ This is not to suggest that anything is to be gained by introdncing traces into 
actual implementations of 00 languages. Our only purpose in introducing traces 
into the operational model is to bring the model closer to the reasoning system so 
that soundness and completeness arguments can be more easily developed. When 
defining a new model in this manner, we must of course ensure that as far as possible 
values that variables that already exist in the original model are concerned, the new 
model agrees with the original model. 

® We have ignored invariants in this argument but they can be added in a straight- 
forward manner. 
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establish the strongest possible post-condition that applies, in the derived class, 
to this method. 

5 Case Study 

The base class for our case study is the Account class defined in Section 2, and 
we will consider two derived classes of Account. We start with, in Figure 3, 
the specifications for the constructor and the hook methods of Account. The 



pre.Account(b) = (b > 0) 
postAccount(b) = (balance = b) 

pre.Account.deposit(x) = (x>0) 

post.Account.deposit(x) = ((x = xQpre) A (balance = balance@pre -|- x)) 
pre. Account, withdraw(x) = (x > 0) 

postAccount.withdraw(x) = ((x = xQpre) A (balance = balance@pre — x)) 
pre.Account.getlnfo() = {true) 

postAccount.getlnfo() = ((balance = balance@pre) A (strmp(balance) ^ result)) (9) 
Fig. 3. Specification of Account class 



specification of the constructor states that the balance in the constructed account 
is initialized to the given value. The specifications for deposit() and withdraw() 
tell us that these methods do not change the value of the parameter x, and that 
they update balance appropriately. 

The specification of getlnfo() is more interesting. Note first that in this post- 
condition we use result to refer to the value returned by this function [Mey97] . 
Also we assume that the string{x) represents the string version of cc; and 
is the prefix relation over strings. Thus this specification tells us that getlnfo() 
leaves balance unchanged, and that the string representation of the balance is 
a prefix of the result returned. The result returned by Account. getlnfo() is in 
fact equal to this string, but the specification allows the derived class designer 
to redefine getlnfo() to return additional information beyond the balance in the 
account (while still satisfying the behavioral subclassing requirement). If our 
specification instead stated that the result returned by getlnfo() was equal to 
balance, the derived class designer would be prevented, by behavioral subclassing, 
from implementing such enrichments. By the same token, the specifications of 
deposit() and withdraw() forbid the redefinition of these methods to, say, impose 
a transaction fee by deducting an additional amount from the balance. It is 
straightforward to show that the bodies of the hook methods of the Account 
class, as defined in Fig. 2, do satisfy the specifications in (9). 

Next consider the template method processTransSeq(). It may be useful to 
briefly summarize the operational behavior of the code, which appears in Fig- 
ure 2, of this method: The method receives a sequence of transaction requests in 
its first parameter transs; it extracts each transaction from transs, and invokes 
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the corresponding method; if the transaction is printinfo, it appends to its second 
parameter results (whose initial value is the empty string) the result returned by 
the call to getinfo; and terminates after processing all the transactions in transs. 

In the e-specification of this method in Fig. 4, we use a number of auxiliary 
functions and predicates; we start by defining these and then will discuss the 
specification. In the definitions below, we use tr to denote a transaction request 
and trs a sequence of such requests; ai will denote a string consisting of account 
information in the format used by processTrans() for outputting, and ais will 
denote a sequence of such strings, r, as usual, will denote the trace of hook- 
method calls: 

IsTransReq{tr): This predicate is true if tr is a ‘legitimate’ transaction request, 
i.e., specifies a transaction (deposit, withdraw, or printinfo), and if the trans- 
action is deposit or withdraw, specifies a positive amount. 
IsTransReqSeq{trs): true if trs is a sequence of legitimate transaction requests. 
|trs|: The length of, i.e. the number of, requests in trs. 
trs[j]: The request in trs. 

trs[i:j]: The subsequence of trs from the request to the 
Trans(tr): The operation (deposit, withdraw, or getinfo) involved in this request; 
note that if the request is for printinfo, the corresponding operation is get- 
lnfo(). 

trs\{deposit}: The subsequence of trs that includes only those transaction re- 
quests for which the transaction involved in the request is deposit; similarly 
for other transactions. 

Amts{trs): The sequence consisting of just the amounts involved in the transac- 
tions in trs (the amount in the case of a printinfo request being taken to be 
0). We will find it useful to refer to the sequence of amounts involved in, say, 
just the deposit transactions; this may be written as ^mts(trs\{deposit}). 
IRNo{trs,k): This value is k' if Trans{trs[k']) is getinfo, and |trs[l:fc']\{getlnfo}| 
is k; in other words, trs[k'] is a printinfo request and is the k*^ such request. 
AccInfo{ai): This predicate is true if ai is a legitimate account-information 

string; i.e., it consists of the character “<” , followed by the balance in the ac- 
count, additional information (this will depend on how getlnfo() is redefined 
in the derived class), and finally “>”. 

AccInfoSeq{ais): This predicate is true if ais is a sequence of legitimate account- 
information strings. 

ais[k]: The account-information string in ais. 

Balance{ai): The balance information in the account-info string ai. 

Info{ai): The entire information, including balance, in the account-info string ai. 
In the case of the base class, this will be identical to Balance(ai) . 

We should also note that when discussing our reasoning system in the preced- 
ing sections, we did not consider the case of a hook method such as getlnfo() 
returning an explicit result. The record, in the trace, of a call to such a method 
will have to include the result returned by the method. If the element of t 
records such a call/return, we will use the notation T[k].re to refer to the result 
returned by this call. 
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In the specification (10), we have numbered some of the lines individually as 
(10.1), (10.2), etc., for easy reference in the discussion. The pre-condition asserts 
that the hook method call trace is empty, as is results, and that transs is a legiti- 
mate sequence of transaction requests. Let us now consider the e-post-condition. 



epre. Account. processTransSeq(transs, results) = (10) 

[(r = e) A (results = e) A {IsTransReqSeqitranss))] 

epost.Account.processTransSeq(transs, results) = 

[(transs = e) A (10.1) 

(balance = (balance@pre -I- 

y~[ Tmts(transs@pre\{deposit}) — 

y~[ Tmts(transs@pre\{withdraw}))) A (10.2) 

(|r| = |transs@pre|) A 

(Vfc : (1 < fc < |r|) :: (r[fc]./im= rrans(transs@pre[fc]))) A (10.3) 

(|results| = |transs@pre\{printlnfo}|) A AccInfoSeq{res\i\ts) A (10.4) 

(Vfe : (1 < fc < |results|) : (fc' = IRNo{transs@pre, k)) :: 

(7n/o(results[fe]) = r[fc'].re) A (10.5) 

{Balance{resii\ts[k]) = (balance@pre -I- 

y~[ Amts{transs@pre[l : k' — l]\{deposit}) — 

^ dmts(transs@pre[l ; fc' — l]\{withdraw})))) (10.6) 



Fig. 4. Specification of Account. processTransSeq() 



(10.1) asserts that the value of transs is empty, i.e., when processTransSeq() fin- 
ishes, all the transaction requests have been processed. (10.2) asserts that the 
final balance in the account is equal to the starting balance, plus the amounts 
deposited into the account, less the sum of the amounts withdrawn, in the var- 
ious transactions. This follows from the fact that the starting balance in the 
account is balance@pre, and from the fact that when processing a deposit/ with- 
draw/ printinfo transaction, processTransSeq() invokes the deposit()/ withdraw()/ 
getlnfo() method which means, given the specification (9) that the deposit() and 
withdraw() methods update the balance by the amount deposited or withdrawn 
and getlnfo() leaves the balance unchanged, that the final balance will be as 
specified in (10.2). 

The next few clauses concern the trace; they assert that the length of r, 
i.e., the number of hook-method-calls is equal to the number of transactions 
requested; and that the particular hook method called {T[k].hm) is the one ap- 
propriate for the transaction. Note, however, that no information is provided 
about the value of the argument passed in the hook method calls (in the calls 
to deposit() and withdraw()). This information could have been provided by in- 
cluding the clause: 



((r[fc]./im = deposit) V (r[fc]./im = withdraw)) {T[k].ia = Amts{transs@pre)\k]) 




324 Neelam Soundarajan and Stephen Fridella 



This simply asserts that if the hook method whose call is recorded in the 
element of r is deposit() or withdraw(), the value of the argument passed to the 
method is the same as the value supplied in the corresponding element of the 
(initial) sequence of transaction requests. In addition, information about the 
state (the value of balance) at the time of these calls is also not provided in 
(10); again, this information could have been provided with a similar clause. 
The fact that these items of information about these hook method calls are not 
included means that the base class designer does not expect enrichments that 
would depend on the values of the arguments passed to the hook methods or on 
the (base class) state at the time of the calls to the hook methods. 

The remaining clauses of (10) give us information about the output that 
processTransSeqO will produce. (10.4) says that there will be as many elements 
in the final value of results as the number of printinfo transaction requests, and 
that each of these elements will be an account-information string. The remain- 
ing clauses are concerned with the individual elements of results; since the 
element of results depends upon the portion of transs@pre that precedes the 
printinfo request in transs@pre, i.e., on transs@pre[l : (/i?A^o(transs@pre, A;) — 1)], 
we have introduced k' as an abbreviation for IRNo{Usnss@pre, k). (10.5) asserts 
that the information in this element of results is equal to the result returned by 
the corresponding call to getlnfo() recorded in r; this clause is important since 
it will allow the derived class designer to establish the enriched behavior of pro- 
cessTransSeqO in the derived class, in particular the enriched output that will 
result from a redefinition of getlnfo(). The final clause (10.6) asserts that the 
balance information in the elements of results correspond to the actual balance 
in the account at the time that the information was added to results. 

Showing that the body of processTransSeq() satisfies this specification is, of 
course, more involved than showing that methods like deposit() satisfy their spec- 
ifications. This is partly due to the fact that we have to reason about the trace 
and partly due to the complexity of processTransSeq(). Thus, for example, deal- 
ing with the loop in processTransSeq() would require us to introduce a suitable 
invariant (which would be very similar to the e-post-condition). We leave the 
formal statement of the loop invariant and the derivation of the e-post-condition 
to the interested reader. 

The f-specification of processTransSeq() is easily stated: 



pre.Account.processTransSeq(transs, results) = (11) 

[(results = e) A {IsTransReqSeq{transs))] 

post.Account.processTransSeq(transs, results) = 

[(transs = er) A (H-1) 

(jresultsj = |transs@pre\{printlnfo}|) A AccInfoSeq{resu\ts) A (11.2) 

(V/c : (1 < A: < jresultsj) : {k' = IRNo{transs@pre, k)) :: 

(5oZance(results[A:]) = (balance@pre 

-I- Amts{transs@pre[l : k' — l]\{deposit}) 

— ^ Amts(transs@pre[l : k' — l]\{withdraw}))) A (11-3) 

(balance = (balance@pre -I- ^ Amts(transs@pre\{deposit}) — 

^ Tmts(transs@pre\{withdraw})))] (H-4) 
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This states that the balance is appropriately updated corresponding to the 
transactions specified in transsOpre and the balance values in the results recorded 
in results represent the balance in the account following the completion of all 
earlier transactions. It is straightforward to check that the required relation, (2), 
between the e- and f-specifications is satisfied. 

Now consider a derived class. TC Account in Figure 5 enriches the behavior 
of the Account class by maintaining a count of the transactions, i.e., the number 
of deposits and withdrawals made on the account; the count is maintained in 
the variable tCount. tCount is initialized to 0 in the constructor. deposit() and 



class TCAccount extends Account { 
protected int tCount; 

// current transaction count 
TCAccount(int b) { tCount := 0; } 
public void deposit(int amt) 

{ balance := balance + amt; tCount++;} 
public void withdraw(int amt) 

{ balance := balance — amt; tCount++;} 
public string getlnfo() 

{res := string(balance); res += "trans count: "; 
res += string(tCount); return(res);} 



} 



Fig. 5. Derived class TCAccount 



withdraw() have been redefined to increment tCount in addition to updating 
balance appropriately. getlnfo() has been redefined so that the result it returns 
contains not only the balance in the account, but also the tCount. 

pre.TCAccount(b) = (b > 0) 

postTCAccount(b) = ((balance = b) A (tCount = 0)) 
pre.TCAccount.deposit(x) = (x>0) 

postTCAccount.deposit(x) = ((x = x@pre) A (balance = balance@pre + x) A 

(tCount = tCount@pre+ 1)) 

pre. TCAccount. withdraw(x) = (x > 0) 

postTCAccount.withdraw(x) = ((x = x@pre) A (balance = balance@pre — x) A 

(tCount = tCount@pre+ 1)) 

pre.TCAccount.getlnfo() = {true) 

postTCAccount.getlnfo() = ((balance = balance@pre) A (tCount = tCount@pre) A 

{result = {string{ha\ance) " "trans count: ’’ " strmp(tCount)))) (12) 

Fig. 6. Specification of TCAccount class 



The specifications for these redefined methods appear in Figure 6. These are 
similar to those in Figure 3; the only changes are that in the post-conditions 
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of deposit() and withdraw(), we specify how they increment tCount, and in the 
post-condition of getlnfo(), we specify that the result returned consists of the 
(string representation of the) balance in the account, followed by the string 
“trans count: ", followed by (the string representation of the) transaction count; 
note that in the last line of (12) denotes string concatenation. It is easy 
to check that the methods defined in Figure 5 satisfy these specifications and 
to check that the specifications in (12) and (9) meet the behavioral subclassing 
requirements since the pre-conditions in (12) are identical to those in (9) and 
the post-conditions in (12) imply the corresponding post-conditions in (9)®. 

Let us now turn to the essential point of our reasoning task, that of incre- 
mentally arriving at the richer behavior of TCAccount.processTransSeq() due to 
the richer behavior of the methods it invokes. The key clause in the base class 
(e-)specification of processTransSeq() that allows such enrichment is (10.5): 

(/n/o(results[fc]) = r[fc'].re) 

First recall, according to the relation between k and k' in (10), that r[k'] records 
the k^^ call to getlnfo(). Now, post.TCAccount.getlnfo() specified in (12) gives us 
more information about the result returned by this call, in other words about 
the value of r[k'] .re, than does post.Account.getlnfo() specified in (9). Specifically, 
whereas (9) states that the result returned by getlnfo() will include the string 
representation of the balance in the account as a prefix, (12) states what the 
rest of the result returned by (TCAccount.)getlnfo() consists of: the string "trans 
count:" followed by the string representation of the value of tCount in the account. 

What will this value be? According to the specfication (12), TCAccount.- 
deposit() and TCAccount.withdraw() both increment tCount by 1. So the value 
that (TCAccount.)getlnfo() reports for tCount in the result it returns will depend 
on the number of calls made so far to these methods. And since these are all 
hook methods, calls to these methods are all recorded on r. We first introduce 
a couple of additional auxiliary functions and predicates which will be of use in 
stating the richer behavior of processTransSeq(): 

TCAccInfo{ai): This predicate is true if ai is a legitimate TC Account-inform- 
ation string; i.e., it consists of “<”, the balance in the account, the string 
“trans count: ”, an integer (being the value of the transaction count in the 
account), and finally, “>”. 

TCAccInfoSeq{ais): This is true if ais is a sequence of legitimate TCAccount- 
information strings. 

Trans Count{tcai): The trans count value recorded in the TC Account-information 
string ai. 

The specification of TCAccount.processTransSeq() appears in Figure 7. The 
pre-condition is the same as in the base class-specification. (13.1) is simply the 
post-condition from the base class-specification; (13.2) and (13.3) specify the 
enrichment. (13.2) should be compared with the (second conjunct of) (10.4); 

® The invariants for both Account and TCAccount are true. 
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epre.TCAccount.processTransSeq(transs, results) = 

[(t = e) a (results = e) A {IsTransReqSeq{trar\ss))] (13) 

epost.TCAccount.processTransSeq(transs, results) = 

[ post.Account.processTransSeq(transs, results) A (13-1) 

rCAcc/n/oS'eg( results) A (13-2) 

(Vfc : (1 < fc < |results|) : (k' = IRNo{transs@pre, k)) :: 

{Trans Count{resu\ts[k]) = 

(tCount@pre+ |transs@pre[l : k' — l]\{deposit, withdraw}|)) )(13.3) 



Fig. 7. Specification of TCAccount.processTransSeq() 



whereas the latter tells us that results is a sequence of strings each of which con- 
sists of followed by the balance in the account, followed (possibly) by some 
additional information, followed by (13.2) also tells us that this additional 
information will be the string “trans count:” followed by (the string representa- 
tion of) the value of tCount in the account at the time this was added to results. 
And (13.3) tells us that this value will be equal to the value of tCount at the 
start of TCAccount.processTransSeqO, plus the number of deposit and withdraw 
transaction requests preceding the printinfo request that led to this TCAccount- 
information string being added to results. 

Let us now see how we can, by using our Enrichment Rule R2, establish (13), 
given the base class e-specification (10) and the derived class behaviors of the 
hook methods specified in (12). The first antecedent of R2 is immediate since the 
e-pre-conditions for the base and derived classes are identical. Now consider the 
second antecedent. Note first that the various clauses ((10.1) through (10.6)) in 
eposf.Account.processTransSeq(transs, results) are such that the substitutions ~r 
by rib, etc.- specified in the first clause of the left side of this antecedent have 
no effect since balance is a member of the base class (hence also of the derived 
class), transs and results are arguments of the method (hence are the same in 
the base and derived classes), and T[k].hm (the identity of the hook method 
invoked in the element of r) and T[k].re (the result returned by this call) 
are the same in the base and derived classes. Therefore, (13.1) will be satisfied 
(given the first clause of the left side of the second antecedent of R2). (13.2) may 
be established as follows: From the second clause of (10.4) we know that each 
element of results is an account-information string; and from (10.5) we know that 
the information in the element of results is the same as the result returned 
by k*^ call to getlnfo(); (13.2) then follows from what posf.TCAccount.getlnfo() 
(defined in (12)) tells us about the result returned by TCAccount.getlnfo(). 

Next consider (13.3). Appealing again to (10.5), we can conclude that 
Trans Count{resu\ts[k]) is equal to TransCount{T[k'].re) 

where k' is IRNo{transs@pre, k). The specification (12) of TCAccount.getlnfo() 
tells us that the transaction count in the result returned by this method is 
the same as the value of tCount at the time the method was called; i.e., equal 
to the value of tCount in the state T[k'].is. The clause ncbc{) in the left side 
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of the second antecedent of R2 tells us, given that tCount is introduced in the 
derived class TC Account, that the value of this variable as recorded in the “initial 
state” (the .is component) of each element of r is the same as its value in 
the “final state” (the ./s component) of the previous element; the clause ccds() 
in the same antecedent tells us that the states as recorded in the .is and .fs 
components of each element of r satisfy the post-condition, specified in (12), of 
the corresponding hook method. Since, according to (12), TCAccount.deposit() 
and TCAccount.withdraw() each increment tCount by 1, and TCAccount.getlnfo() 
leaves it unchanged, we can then conclude that the transaction count in the result 
returned by the call to getlnfo() recorded in the element of r is equal to the 
value of tCount at the start of processTransSeq() plus the number of calls to 
deposit()/withdraw() recorded in the first (fc' — 1) elements of r. This, combined 
with (10.3), lets us conclude that (13.3) must be satisfied. 

And finally, consider the f-specification of TCAccount.processTransSeq(); we 
express this in terms of the pre- and post-conditions of the f-specification of 
Account. processTransSeqO, spelling out only the additional clauses: 

pre.TCAccount.processTransSeq(transs, results) = (14) 

pre.Account.processTransSeq(transs, results) 

post.TCAccount.processTransSeq(transs, results) = 
[post.Account.processTransSeq(transs, results) A (14.1) 

TCAccInfoSeq{resu\X.s) A (14.2) 

(Vfc : (1 < fc < |results|) : (fc' = ZRAo(transs@pre, k)) :: 

{TransCount{resu\ts[k]) = 

(tCount@pre -I- |transs@pre[l : k' — l]\{deposit, withdraw}|)) ) ] (14.3) 

Again it is straightforward to check that the relation (2) holds between the 
e-specification (13) and the f-specification. 

Note that the clause (14.1) follows from behavioral subclassing considera- 
tions, given that (12) is consistent with (9) If all we were interested in was to 
show that TCAccount. processTransSeqO behaves in a way consistent with the 
(f-)specification of Account. processTransSeqO, we would not need the formalism 
developed in this paper. But, of course, the whole point of defining the derived 
class, in particular of redefining the hook methods in the TCAccount class, was 
to enrich the behavior of the template method processTransSeqO as specified in 
(14.2) and (14.3). And it is this enriched behavior that our formalism allows us 
to establish. And in establishing this enriched behavior, we did not have to rean- 
alyze the behavior of the code of this method; instead, we plugged in the richer 
behavior of the derived class hook methods into the e-specification, established 
during the base-class analysis, of the template method. 

We will conclude this section with two remarks. First, suppose we defined 
a variation of TCAccount in which only large transactions, i.e., those in which 
the amount involved is greater than 5000 are counted. Then we cannot rea- 
son about the resulting richer behavior of processTransSeqO on the basis of the 
specification (10) since that specification does not tell us what argument values 
processTransSeqO passes to the hook methods it calls. It would have been easy 
enough to include this information in (10); it is up to the base class designer 




Incremental Reasoning for Object Oriented Systems 329 



to anticipate what kinds of enrichments might be implemented in the derived 
classes and include the appropriate information in the e-specifications. Being 
too liberal here, that is allowing for all kinds of enrichments, would lead to very 
complex e-specifications; being too conservative will make it impossible to reason 
incrementally about enrichments that were not anticipated. This is a trade-off 
between flexibility of design versus complexity of specs. 

Our second observation has to do with the nature of our e-specifications. 
E-specifications are most conveniently expressed, as in the case of 
Account. processTransSeqO, by first defining some useful functions on traces that, 
in a sense, mimic the behavioral pattern exhibited by the template method, and 
then writing down the e-specification of the method in terms of these functions. 
For more complex situations, we believe it would be useful to introduce spe- 
cialized notation for use in writing such specifications, perhaps using constructs 
similar to those of regular expressions; we plan to investigate such notations in 
future work. 



6 Related Work 

A number of authors have addressed questions relating to reasoning about be- 
havioral issues in 00 systems. Lamping [Lam93] proposes specifying, for each 
polymorphic function of a class, the set of virtual functions that it invokes. This 
will allow a derived class designer to know whether a given polymorphic func- 
tion might be affected -enriched in our terminology- by redefinitions of specific 
virtual functions. The idea seems to be that the designer can then go back and 
study the code of the polymorphic function in the base class to see how it is af- 
fected; our goal of course is to try to avoid such reanalysis. Kiczales and Lamping 
[KL92] propose providing information not just about which virtual functions the 
polymorphic function will call but also the order in which it will call them. But 
they don’t talk about establishing behavioral specifications or about arriving at 
the enriched behavior of the polymorphic method in the derived class by plug- 
ging in, into the base class specification, information about the behavior of the 
redefined virtual methods. 

Behavioral problems arising from careless use of inheritance have been dis- 
cussed by a number of authors, see for example [Sak89]. It is, as we noted earlier, 
to address this problem that the notion of behavioral subtyping was developed; 
our work extends this since our goal is not just to guarantee that the base-class- 
level analysis of the template method remains valid in the derived class but also 
to reason about the richer behavior of the template method in the derived class. 
We should also note that a class A may be a behavioral subtype of a class B 
independently of whether or not A is defined as a derived class of B. Dhara and 
Leavens [DL96] focus on the conditions that will ensure that a derived class will 
be a behavioral subtype of its base class so there is a natural connection to our 
work since the primary focus of this paper is the relation between the behaviors 
of derived and base class. But note that Dhara and Leavens, like other authors 
who deal with behavioral subtyping, do not address the question of the enriched 
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behavior resulting from the redefinition of methods in the derived class which is 
our main concern. Stata and Guttag’s [SG95] interest is somewhat similar to that 
of [DL96] . They extend the notion of behavioral subtyping to deal with redefi- 
nitions of groups of virtual methods in the derived class, but again the question 
of reasoning about the richer behavior in the derived class is not addressed. Ed- 
wards [Edw97] considers the reasoning reuse that may be achieved if the derived 
class is not necessarily a behavioral subtype of the base class but certain other 
conditions, such as the invariant for the derived class being the same as that for 
the base class, are satisfied. But as we just saw, if we want to be able to reason 
incrementally about the behavior of template methods, behavioral subtyping (or 
rather behavioral subclassing) is essential. 

Abadi and Leino [AL97] propose a logic for reasoning about 00 programs 
expressed in a simple language that they define. They do not have classes in their 
language; each object, in the logic, ‘carries’ with it the specifications of its various 
methods. In addition, the logic takes explicit account of object creation via the 
alloc{) function; this allows them to deal with aliasing between objects. But 
[AL97] does not address the question of reasoning about polymorphic methods; 
in particular it is not clear that we would be able to reason incrementally about 
the behavior of the polymorphic method from its specification in the base class 
(or object); instead, it seems likely that one would have to re-reason about the 
(body of the) polymorphic method in the context of the new class to arrive at 
its derived-class behavior. 

Buchi and Week’s [BW99] work is closer to our approach. They note that 
pre- and post-conditions on just the values of member variables are inadequate 
when dealing with template methods and that one must also make use of traces. 
They introduce a formalism and a programming language-like notation using 
which some information about the trace of hook method calls can be specified. 
Although their use of traces is similar to ours, Buchi and Week focus only on 
specifying conditions that the trace must satisfy, not the question of how to 
use such specifications to arrive at the richer behavior that results from the 
redefinitions of the hook methods in the application. It is also worth noting 
that traces have been used extensively [Dah92, Hoa85, MG81] for reasoning 
about communicating processes. The soundness and completeness arguments 
we sketched are quite similar to the proofs of soundness and completeness of a 
trace-based GSP proof system in [SD82]. 

Keidar et al. [KKLSOO] present a formal system for arriving at specifications 
and proofs incrementally. But the kind of inheritance they use is not related to 
inheritance (of code) from base to derived classes in standard 00 languages; 
rather, their ‘inheritance’ has to do with starting with the specification for an 
automaton and arriving at the specification for another automaton that exhibits 
additional behavior. In particular, [KKLSOO] does not deal with incremental 
reasoning about the behavior of template methods. 

Garlan et al. [GJND98] develop a temporal-logic based approach to reasoning 
about implicit invocation. Galls to hook methods from template methods can 
be considered implicit invocations since the actual method invoked cannot be 
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determined from just the body of the template method but also depends on the 
derived class under consideration. While there are some similarities with our 
work, a key difference is that whereas we first reason about the base class and 
then arrive incrementally at the behavior of the derived class, [GJND98] takes a 
very different approach: Given a system S (consisting of all the methods defined 
in all the classes) and a specification for S, partition S into a number of groups, 
arrive at a suitable specification for each group, show that each group satisfies its 
specification, and show that together the specifications of the individual groups 
imply the original specification of S. 

7 Discussion 

One of the most important ideas introduced by Simula was the notion of poly- 
morphism. Polymorphism allows a derived class designer to enrich the behavior 
of the template methods of the base class by redefining one or more of the hook 
methods that the template methods invoke. If the base class has been designed 
carefully and includes the right hooks and the template methods invoke these 
at the right points, different derived class designers can achieve different enrich- 
ments, appropriate to their particular applications, with relatively little effort; 
much has been written about the central role that polymorphism plays in build- 
ing flexible, extensible 00 systems see, for example, [Mey97]. The work reported 
in this paper has been motivated by the belief that the techniques that we use to 
reason about the behaviors exhibited by such systems must similarly be incre- 
mental, in other words, that we must provide suitable characterizations of the 
behaviors of the base class template methods so that we can arrive at the richer 
behaviors they exhibit in the derived class by simply plugging-in appropriate 
information about the redefined hook methods. Although much work has been 
done in the past few years in developing reasoning systems for dealing with 00 
systems, most of this work, in particular the work on behavioral subtyping (and 
subclassing), has focused on ensuring that base class specifications of template 
methods continue to be satisfied even with the derived class redefinitions of the 
hook methods. Our main contribution has been to extend this to allow us to 
reason also about the richer behavior that the template methods exhibit as a 
result of these redefinitions of the hook methods. 

The key component of our approach that makes it possible to reason about 
this richer behavior without having to reanalyze the code of the template method 
is what we called the e-specification of a template method. The e-specification 
gives us information about the trace of hook method calls that the template 
method in question makes and its relation to the behavior the template method 
exhibits. Although the e-specification is more complex than the standard (f-) 
specification that only specifies information about the values of the member 
variables of the class, it is clear that an incremental reasoning system must 
include information about the trace of hook method calls since that is the source 
of the power of polymorphism. 
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In this paper, we have considered only a single base class and the derived 
classes that might be defined from it. In a complex 00 system, there will of 
course be many objects that are instances of a variety of classes. Indeed, this 
corresponds naturally to a distributed system with the individual objects cor- 
responding to the processes of the distributed system. There are of course ad- 
ditional issues to be considered in such a system such as synchronization. It 
has been observed that this can introduce additional new problems such as the 
inheritance anomaly [MY93]. In future work, we hope to extend our reasoning 
system to deal with behavioral issues in such systems. The fact that traces which 
play such a key role in our system also occur naturally when dealing with the 
behavior of distributed systems [Hoa85, MC81] suggests that such an approach 
is indeed reasonable. 
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Abstract. The logical and operational aspects of rewriting logic as a 
logical framework are tested and illustrated in detail by representing 
pure type systems as object logics. More precisely, we apply membership 
equational logic, the equational sublogic of rewriting logic, to specify pure 
type systems as they can be found in the literature and also a new variant 
of pure type systems with explicit names that solves the problems with 
closure under a-conversion in a very satisfactory way. Furthermore, we 
use rewriting logic itself to give a formal operational description of type 
checking, that directly serves as an efficient type checking algorithm. The 
work reported here is part of a more ambitious project concerned with 
the development of the open calculus of constructions, an equational 
extension of the calculus of constructions that incorporates rewriting 
logic as a computational sublanguage. 



This paper is a detailed study on the ease and naturalness with which a family 
of higher-order formal systems, namely pure type systems (PTSs) [6,50], can 
be represented in the first-order logical framework of rewriting logic [36] . PTSs 
generalize the A-cube [1], which already contains important calculi like A-^- [12], 
the systems F [23,43] and Fw [23], a system AP close to the logical framework 
LF [24], and their combination, the calculus of constructions CC [16]. PTSs 
are considered to be of key importance, since their generality and simplicity 
makes them an ideal basis for representing higher-order logics, either via the 
propositions-as- types interpretation [21], or via their use as a higher-order logical 
framework in the spirit of LF [24,20] or Isabelle [39]. 
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Exploiting the fact that rewriting logic (RWL) and its membership equational 
sublogic (MEL) [10] have initial and free models, we can define the representa- 
tion of PTSs as a parameterized theory in the framework logic; that is, we define 
in a single parametric way all the representations for the infinite family of PTSs. 
Furthermore, the representational versatility of RWL, and of MEL, are also ex- 
ercised by considering four different representations of PTSs at different levels 
of abstraction, from a more abstract textbook version in which terms are iden- 
tified up to a-conversion, to a more concrete version with a calculus of names 
and explicit substitutions, and with a type checking inference system that can 
in fact be used as a reasonably efficient implementation of PTSs by executing 
the representation in the Maude language [13,14]. 

This case study complements earlier work [31,32], showing that rewriting 
logic has good properties as a logical framework to represent a wide range of 
logics, including linear logic, Horn logic with equality, first-order logic, modal 
logics, sequent-based presentations of logics, and so on. In particular, represen- 
tations for the A-calculus, and for binders and quantifiers have already been 
studied in [32], but this is the first systematic study on the representation of 
typed higher-order systems. One property shared by all the above representa- 
tions, including all those discussed in this paper, is that what might be called 
the representational distance between the logic being formalized and its rewriting 
logic representation is virtually zero. That is, both the syntax and the inference 
system of the object logic are directly and faithfully mirrored by the represen- 
tation. This is an important advantage both in terms of understandability of 
the representations, and in making the use of encoding and decoding functions 
unnecessary in a so-called adequacy proof. 

Besides the directness and naturalness with which logics can be represented in 
a framework logic, another important quality of a logical framework is the scope 
of its applicability; that is, the class of logics for which faithful representations 
preserving relevant structure can be defined. Typically, we want representations 
that both preserve and reflect provability; that is, something is a theorem in 
the original logic if and only if its translation can be proved in the framework’s 
representation of the logic. Such mappings go under different names and differ in 
their generality; in higher-order logical frameworks representations are typically 
required to be adequate mappings [20], and in the theory of general logics more 
liberal, namely conservative mappings of entailment systems [35], are studied. 
In this paper, we we further generalize conservative mappings to the notion of 
a sound and complete full correspondence of sentences between two entailment 
systems. In fact, all the representations of PTSs that we consider are correspon- 
dences of this kind. Sound and complete full correspondences are systematically 
used not only to state the correctness of the representations of PTSs at differ- 
ent levels of abstraction, but also to relate those different levels of abstraction, 
showing that the more concrete representations correctly implement their more 
abstract counterparts. 

A systematic way of comparing the scopes of two logical frameworks T and 
Q is to exhibit a sound and complete full correspondence T ^ Q, representing 
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T in Q. In view of this quite general concept, it is important to add that the 
representational distance, which we informally define as the complexity of this 
correspondence, is an important measure of the quality of the representation. 
Since such correspondences form a category, and therefore compose, this then 
shows that the scope of Q is at least as general as that of T . Since PTSs include 
the system AP, close to the logical framework LF, and the calculus of construc- 
tions CC, the results in this paper indicate that the scope of rewriting logic is at 
least as general as that of those logics. Furthermore, since there are no adequate 
mappings from linear logic to LF in the sense of [20] , but there is a conservative 
mapping of logics from linear logic to rewriting logic [32], this seems to indicate 
that the LF methodology together with its rather restrictive notion of adequate 
mapping is more specialized than the rewriting logic approach. 

In this paper we will be concerned with PTSs as formal systems represented 
inside informal set theory, or inside another formal system such as rewriting 
logic or its membership equational sublogic. For formal systems in general, and 
for PTSs in particular, there is not a single canonical presentation. Instead each 
presentation is tailored for specific purposes. For example, there are different for- 
mulations of PTSs with different sets of rules, but the same sets, or related sets, 
of derivable sentences. Furthermore, presentations can be more or less abstract, 
e.g. concerning the treatment of names, or concerning the degree of operational- 
ity. It is needless to say that the use of some general terminology is highly 
desirable in this situation to deal with these issues in a systematic way. To this 
end, we follow the general logics methodology [35] to use an abstract logical 
metatheory, which is concerned with formal systems and their relationships, to- 
gether with a particular formal system as a logical framework, namely rewriting 
logic. Regarding general logics terminology, we furthermore found that the no- 
tion of correspondences between sentences that generalizes the idea of maps of 
entailment systems is a simple a useful tool to structure our results. 

In summary, we think that, besides the more technical contributions to PTSs 
discussed in Section 5, the key contributions of this paper are threefold. First, 
as already mentioned, the expressiveness of RWL and its MEL sublogic as log- 
ical frameworks is tested and demonstrated by showing how a well-known fam- 
ily of typed higher-order logics, that are themselves frequently used for logical 
framework purposes, are naturally represented. But this brings along with it 
a second important consequence: our representation maps suggest fruitful gen- 
eralizations of PTSs, in which higher-order reasoning is seamlessly integrated 
with equational and rewriting logic reasoning. The need for such multiparadigm 
integrations of equational logic and type theory is clearly recognized by many 
researchers, because of the restrictive notions of equality and computation in tra- 
ditional A-calculi. Specifically, as further explained in Section 5.1, an integration 
of a typed higher-order A-calculus with MEL and RWL, namely the open calculus 
of constructions (OCC) [48], has been developed by the first author as a natural 
extension and generalization of the ideas presented here. It is worth pointing out 
that the executability of the representation maps has made possible the devel- 
opment of a prototype for OCC in Maude which has been used in a wide range 
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of examples concerned with programming, specification and interactive theorem 
proving [48]. A third and final consideration is that our representation maps 
have another important advantage: since MEL and RWL theories have initial 
models, theories with initial semantics can be endowed with inductive reasoning 
principles. It is indeed such an initial (or free extension) semantics that is used 
in all our representations of PTSs. This means that we can not only simulate 
PTSs in MEL or RWL using our representations, but we can also reason about 
the metalogical properties of such systems using induction. Different approaches 
to metalogical reasoning are touched upon in Section 5.2. These include the use 
of a higher-order logic such as OCC as a metalogic to reason about formalisms 
represented in its MEL or RWL sublogic, and the use of a reflective metalogical 
framework such as RWL, which is discussed at greater length in [4]. 

1 Preliminaries 

1.1 Entailment Systems 

In the following sections we are concerned with a variety of different interrelated 
formal systems that can all be viewed as entailment systems, a notion defined in 
[35] as a main component of general logics. Since the notion of entailment system 
is more general than what is needed for the purposes of the present paper, we 
work with unary entailment systems over a fixed signature. A unary entailment 
system (Sen, h) is a set of sentences Sen, together with a unary entailment 
predicate hC Sen. 

In [35] maps between sentences are used to relate different logics. Here we 
introduce a more general notion of morphism, namely a correspondence between 
sentences of different entailment systems. Let (Sen, h), (Sen',f-') be unary en- 
tailment systems. A correspondence of sentences between (Sen, h) and (Sen', h') 
is a relation r\ C Sen x Sen'. Given such a correspondence r\, we say that 
o is sound iff for all (j) r\ (j)' , h' (j)' implies h (j). Similarly, we say that is 
complete iff for all (j> r\ (f>' , \- <j> implies h' (j)' . Moreover, r\ is called total iff for 
each (j)' G Sen' there is a such that (j) r\ (f>' . Correspondences compose in the 
obvious relational way, giving rise to a category CEnt. Often a correspondence 
of sentences r\ C Sen x Sen' takes the form of a function a : Sen — > Sen', 
but in principle it can also take the form of a function a : Sen' — > Sen in the 
opposite direction. Indeed, a map of entailment systems a : Sen' — > Sen in the 
sense of [35] gives rise to a sound correspondence a~^ C Sen x Sen', and if a is 
a conservative map then a~^ is a sound and complete correspondence. 



1.2 Rewriting Logic and Membership Equational Logic 

A rewrite theory is a triple 7Z = (A, E, R), with A a signature of function sym- 
bols, E a set of equations, and R a set of (possibly conditional) rewrite rules of 
the form t — > t' (with t and t' A-terms) which are applied modulo the equa- 
tions E. Rewriting logic (RWL) has then a deductive system to infer all possible 
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rewrites provable in a given rewrite theory [36] . Since an equational theory {S, E) 
can be regarded as a rewrite theory (E, E, 0) with no rules, equational logic is a 
sublogic of rewriting logic. In fact, rewriting logic is parameterized by the choice 
of its underlying equational logic, which can be unsorted, many-sorted, and so 
on. 

In this paper, and in the design of the Maude language, we have chosen 
membership equational logic (MEL) [37,11] as the underlying equational logic. 
Membership equational logic is quite expressive. It has sorts, subsorts, over- 
loading of function symbols, and can express partiality very directly by defining 
membership in a sort by means of equational conditions. The atomic sentences 
are equalities t = t' and memberships t \ s, with s a sort, and general sentences 
are Horn clauses on the atoms. Both membership equational logic and rewrit- 
ing logic have initial and free models [36,37]. We denote by MEL C RWL the 
sublogic inclusion from membership equational logic into rewriting logic. 

Logics can be naturally represented as rewrite theories by defining the for- 
mulas, or other proof-theoretic structures such as sequents, as elements of appro- 
priate sorts in an abstract data type specified by an equational theory {S,E). 
Then, each inference rule in the logic can be axiomatized as a, possibly condi- 
tional, rewrite rule, giving rise to a representation as a rewrite theory {S , E, R). 
Alternatively, we can exploit the rich sort structure of membership equational 
logic to represent the inference rules of a logic not as rewrite rules, but as Horn 
clauses El expressing membership in an adequate sort of derivable sentences, 
leading to a membership equational logic representation of the form (A, EUH). 
In this paper we will use both forms of representations for different versions of 
PTSs. 

2 Overview and Main Results 

In Section 3 we show how the definition of PTSs can be formalized in MEL. The 
approach we use is not only less specialized than the one used in a higher-order 
logical framework like LF [24] or Isabelle [39] , but it has also more explanatory 
power, since we explain higher-order calculi in terms of a first-order system with 
a simpler semantics, and our representations have initial (or, more generally, free 
extension) models supporting metalogical inductive reasoning about the PTSs 
thus represented. 

In order to make the specification of PTSs more concrete, we introduce in 
Section 3.5 the notion of uniform pure type systems (UPTSs) [46,49,48], that 
do not abstract from the treatment of names but use CINNI [47,48], a generic 
the first-order calculus of names and substitutions. UPTSs solve the problem 
of closure under a-conversion, that has been discussed by Pollack in [40], in 
a simple and elegant way. Again, a MEL specification of UPTSs is given that 
directly formalizes the informal definition. 

As an intermediate step we employ optimized UPTSs (OUPTSs) which are 
introduced in Section 3.6. OUPTSs have an explicit judgement for well-typed 
contexts, and can be seen as a refinement of UPTSs towards a more efficient 
implementation of type checking. 
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Last but not least, we describe how the meta-operational view of an im- 
portant class of OUPTSs, namely type checking and type inference, can be ex- 
pressed as a transition system and can likewise be formalized in rewriting logic. 
The result of this formalization is an executable specification of rewriting-based 
OUPTSs (ROUPTSs) that is sound w.r.t. the logical specification given before 
in a very obvious way. 

Formally, these different presentations of PTSs are families of unary entail- 
ment systems parameterized by PTS signatures. We use the notation PTSg, 
UPTS5, OUPTS5 and ROUPTS5 to denote the entailment systems of PTSs, 
UPTSs, OUPTSs, and ROUPTSs, respectively, associated with a PTS signature 

S. 

For appropriate PTS signatures S we obtain a chain of sound and complete 
total correspondences 

PTSs ^ UPTSs ^ OUPTSs o ROUPTSs. 

Actually, we have two different kinds of connections between the first two en- 
tailment systems, leading to two different correspondences of the form PTSs ^ 
UPTSs. By composing three correspondences of the form above we finally arrive 
at a sound and complete total correspondence 

PTSs ^ ROUPTSs 

which shows the equivalence of the high-level specification of PTSs with the 
implementation of a type checker. 

The deductive system of RWL induces a unary entailment system RWL with 
sentences of the form TZ\- (j), where 7^ is a rewrite theory and 4> is an equation, 
a membership or a rewrite. In this chapter we abstract from rewrite proofs, so 
that we use the term rewrite to refer to a sentence of the form M — > M' and 
we define TZ \~ M ^ M' to be derivable iff 7^ h P : M ^ M' is derivable for 
some rewrite proof P in the deductive system of RWL. Likewise, MEL induces a 
unary entailment system MEL obtained by restricting TZ to MEL theories and 
(j) to equations or memberships. 

The entailment systems PTS5, UPTS5, OUPTS5 and ROUPTS5 can be 
easily specified in membership equational logic or in rewriting logic. Specifically, 
we have the following sound and complete total correspondences: 

PTSs ^ MEL 

UPTSs ^ MEL 
OUPTSs MEL 
ROUPTSs o RWL 

In all cases the representational distance between the formal system and its 
representation is practically zero, that is, both the syntax and the inference 
system of each version of PTSs have direct and faithful representations in the 
framework logic. 
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The first correspondence is the representation of PTSs in MEL given in Sec- 
tion 3. Let PTSs be the MEL specification of PTSs- Then, for all PTS judge- 
ments 4> of PTSs and possible representations (j)' of (p in MEL, the sentence 
PTSs b 4>' is derivable in MEL iff the judgement (p is derivable in PTSs- This 
defines a sound and complete total correspondence of the form PTSs ^ MEL. 
We are concerned with a correspondence rather than a function, due to the 
fact that PTSs abstract from names, but in the MEL representation names are 
part of the description of terms, although by adding appropriate equations an 
equivalent abstraction can be achieved in MEL at the semantic leveL 

In the remaining three systems UPTSs, OUPTSs, and ROUPTSs we 
do not abstract from names- Hence, the three associated representational corre- 
spondences actually take the form of functions, i-e-, with each judgement of the 
type system we can associate a unique sentence in MEL or RWL, respectively- 
For the presentation of PTSs we follow [52] , which can be seen as an informal 
presentation of the machine-checked formalization [34] . 

3 The Metalogical View of PTSs 

A PTS signature is a triple (5, A, TZ) where 5 is a set of sorts, A C 5 x 5 is the 
set of axioms, and TZCSxSxSis the set of rules. The sorts of a PTS signature 
are used as types of types and are therefore often referred to as universes. We 
use S to range over PTS signatures, and for the following we fix an arbitrary 
PTS signature S. 

In PTSs there is no a priori distinction between terms and types- PTS terms 
are defined by the following syntax with binders: 

X\{M N)\[X : A]M \ {X : A}M \ s 

Here, and in the following, s ranges over S; M, N, A, B, T range over terms; and 
X ranges over names- We should add that in \X : A\M and {X : A}M the name 
X is bound in M , and we assume that a-convertible terms, i-e- terms that are 
equal up to renaming of bound variables, are identified - 

Formally this identification can be achieved by different means: the definition 
of PTS terms as equivalence classes modulo a-equivalence, or a representation 
based on de Bruijn indices are two possibilities- For the following it is important 
to keep in mind that the choice of particular names for bound variables is part 
of the informal notation (for readability) but is not reflected in PTS terms- 
A PTS context is a list of declarations, each of the form X \ A. X declaration 
X : A declares a name X of type A. A context is simple if it declares each 
identifier at most once- In the following, P ranges over PTS contexts- 

PTS typing judgements are of the form P \- M : T, and derivability, i-e- the 
set of derivable typing judgements, is defined by the formal system given by the 
following inference rules: 
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[] h Si : S2 



(si, S 2 ) G A 



FhA-.s 
r,X -.Ah X : A 



X i r 



rh M : A rh B : s 
r,X ■. B'r M ■. A 



X 



(Ax) 

(Start) 



(Weak) 



T h A : Si r,X ■. A'^ B ■. S2 

B'r {X-. A}B : S 3 



(si, S2, S3) G TZ 



(Pi) 



ThA:si r,X:AhM-.B r,X:AhB-.S2 
T h [X : A]M : {X : A}B 



(S1,S2,S3) G TZ 



(Lda) 



T h M : {X : A)B B ^ N ■. A 
T h (M X) : [X-.=A]B 

r'r M ■. A r'r B ■. s , 



(App) 

(Conv) 



Here we write X ^ T iff there is no X : H G T for any A, and we denote by 
[X := N]M the standard (capture-free) substitution of all free occurrences of 
X in M by X. In the last rule, =/3 is the usual notion of /3-convertibility, which 
contains a-convertibility (this is trivially satisfied in this presentation) . Observe 
that the side conditions ensure that we can only derive simple judgements, i.e. 
judgements with simple contexts. We say that T is a type in the context B iff 
T£SovB\~T\ s for some s G S. Furthermore, M is said to be an element 
of type T in the context B iS B \- M : T, in which case we also say that M is 
well-typed in B. 

As an example, we can instantiate PTSs by 

S = {Prop, Type}, 

A = {(Prop, Type)}, 

TZ = {(Prop, Prop, Prop), 

(Prop, Type, Type), 

(Type, Prop, Prop), 

(Type, Type, Type)} 

to obtain the calculus of constructions. 

This presentation of PTSs is rather abstract for two reasons: firstly, we are 
working modulo a-conversion, i.e., we identify a-convertible terms, and secondly, 
we are concerned with an inductive definition of a set of derivable judgements, 
but not with an algorithm to verify derivability of a given judgement. 

Mathematically the abstract presentation has an important benefit: It allows 
us to reason about PTSs metalogic ally, without assuming anything about the 
concrete realization of names. This leads to very general results [1,51] and frees 
proofs from unnecessary technical details. 
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Closure under a-conversion is the property that derivability oi F \- M \ A 
and M =a M' implies derivability of C h M' : A. Of course, this property 
trivially holds for PTSs as presented above, since =„ is the identity. To state 
a stronger property we extend a-conversion =„ from terms to judgements such 
that r \- M ■. A =a F' h M' : A! iff F' h M' : A' and F \- M : A are equal up to 
consistent renaming of variables. Then we have the following 

Lemma 31 (Strong Closure under o-Conversion for PTSs) 

Let M, A, M' , A' be PTS terms and T, F' be PTS contexts. If the PTS judge- 
ment F \- M ■. A is derivable in PTS 5 and F \- M \ A =„ F' h M' : A' , then 
F' h M' : A' is derivable in PTSg. 

Proof Sketch. By induction over derivations oi F \- M ■. A. □ 

The previous Lemma is equivalent to the statement that the following rule 
is admissible in PTSs: 

r \- M ■ A 

F' h M' '■ A' if ^ ^ ^ ^ ^ (Rename) 



3.1 PTSs in Membership Equational Logic 

In the following specifications, given in Maude syntax, we use the algebraic se- 
mantics of MEL for representing PTSs exactly as given above; a more operational 
version suited for use as an implementation is discussed in Section 4.2. 

First, notice that we plan to describe not a single type system but the infinite 
family of PTSs parameterized by PTS signatures which define sorts, axioms and 
rules. All such PTS signatures can be formalized as models of a single parameter 
theory that can be specified in Maude as follows: 

fth PTS-SIG is 

sorts Sorts Axioms Axioms? Rules Rules? . 

subsort Axioms < Axioms? . 

subsort Rules < Rules? . 

op : Sorts Sorts -> Axioms? . 

op : Sorts Sorts Sorts -> Rules? . 

endfth 

As an example, the PTS signature of CC is given by the following functional 
module: 

fmod CC-SIG is 

sorts Sorts Axioms Axioms? Rules Rules? . 
subsort Axioms < Axioms? . 
subsort Rules < Rules? . 
op : Sorts Sorts -> Axioms? . 

op : Sorts Sorts Sorts -> Rules? . 
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op Prop : -> Sorts . 
op Type : -> Sorts . 

mb (Prop, Type) : Axioms . 
mb (Prop, Prop, Prop) : Rules . 
mb (Prop, Type, Type) : Rules . 
mb (Type, Prop, Prop) : Rules . 
mb (Type, Type, Type) : Rules . 

endfm 

PTSs can then be specified as a functional module parameterized by the the- 
ory PTS-SIG. Since functional modules have an initial (in this case free) model 
semantics, this formalization of PTSs is in fact a parameterized inductive defi- 
nition that captures in a precise model-theoretic way the inductive character of 
PTS rules. 

fmod PTS[S : : PTS-SIG] is 

First we define the sort Trm of terms as an algebraic data type. Notice that 
we distinguish between a sort of names Qid, that are used in places where a 
variable is declared, and a sort of variables Var, that are used to refer to an 
already declared variable. 

sorts Var Trm . 
subsort Qid < Var . 

subsort Var < Trm . 

subsort Sorts < Trm . 

op : Trm Trm -> Trm . 

op ; Qid Trm Trm -> Trm . 

op : Qid Trm Trm -> Trm . 

vars s si s2 s3 : Sorts . 
vars X Y Z : Qid . 

vars A B M N 0 P Q R T A’ B’ M’ N’ T> : Trm . 

The usual deterministic version of capture-free substitution can be naturally 
defined in MEL as demonstrated in [32]. An important point is that we do 
not want to restrict ourselves to a particular choice of fresh names, since this 
would make the specification overly concrete. This can be accomplished by leav- 
ing unspecified the deterministic function for choosing fresh variables such that 
the actual function varies with the choice of the model; for details we refer to 
[32]. Here we only give the signature for set membership, free variables and the 
substitution function: 

op _in_ : Qid QidSet -> Bool . 
op FV : Trm -> QidSet . 
op : Qid Trm Trm -> Trm . 
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We can use the substitution operator [_ : =_] _ to semantically identify terms 
that are a-convertible (we refer to the induced equality as a-equality) by means 
of the following equations. 

ceq [X : A] M = [Y : A] ([X := Y] M) if not (Y in FV(M)) . 

ceq {X : A} M = {Y : A} ([X ;= Y] M) if not (Y in FV(M)) . 

We next define the binary relation of /3-convertibility, which is used in the 
Conv rule of PTSs. The following (conditional) memberships, together with the 
initiality condition, define /3-conversion as the smallest congruence (w.r.t. the 
term constructors) containing /3-reduction. 

sorts Convertible Convertible? . 

subsort Convertible < Convertible? . 

op : Trm Trm -> Convertible? . 

mb M <-> M : Convertible . 

cmb M <-> N : Convertible 

if N <-> M : Convertible . 

cmb P <-> R : Convertible if 

P <-> Q : Convertible and Q <-> R : Convertible . 

cmb (M N) <-> (M’ N’) : Convertible if 

M <-> M’ : Convertible and N <-> N’ : Convertible . 

cmb ([X : A] M) <-> ([X : A’] M’) : Convertible if 

A <-> k’ : Convertible and M <-> M’ : Convertible . 

cmb ({X : A} B) <-> ({X : A’} B’) : Convertible if 

A <-> A’ : Convertible and B <-> B’ : Convertible . 

mb (([X : A] M) N) <-> ([X := N] M) : Convertible . 

The judgements of PTSs are of the form F \- M : A. We next define the 
syntax of contexts and judgements. Also, we define the function _in_ used in 
the side conditions of some PTS rules. 

sorts Context Judgement . 

op emptyContext : -> Context . 

op _ : _ : Qid Trm -> Context . 

op : Context Context -> Context [assoc id : emptyContext] . 



var G : Context . 
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op : Context Trm Trm -> Judgement . 

op _in_ : Qid Context -> Bool . 

eq X in emptyContext = false . 

eq X in (G, (Y : A)) = (X in G) or (X == Y) . 

We are now ready to define the inference rules. Semantically, the inference 
rules define an inductive subset of derivable judgements. The derivability predi- 
cate is usually implicit in informal reasoning, where F \- M \ A refers either to 
the judgement itself or to the fact that it is derivable. 

sort Derivable . 

subsort Derivable < Judgement . 



cmb 


(emptyContext |- si : 


s2) : Derivable 


if (sl,s2) : Axioms 


cmb 


(G, 


(X 




A) 1- X : A) : 


Derivable if 






(G 


1- 


A 


: s) : Derivable /\ not(X in 


G) . 


cmb 


(G, 


(X 




B) 1- M : A) : 


Derivable if 






(G 


1- 


M 


: A) : Derivable /\ 






(G 


1- 


B 


: s) : Derivable /\ not(X in 


G) . 


cmb 


(G 


1- 


{X : A} B : s3) 


: Derivable if 






(G 


1- 


A 


: si) : Derivable /\ 






(G, 


(X 




A) 1- B : s2) 


: Derivable /\ 


(sl,s2,s3) : Rules . 
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(G 
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[X : A] M : {X : 


A} B) : Derivable if 




(G 
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: si) : Derivable /\ 
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(X 
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Derivable /\ 
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: Derivable /\ 


(sl,s2,s3) : Rules . 
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(G 
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(M N) : [X := A] 


B) : Derivable 


if 




(G 


1- 


M 


: {X : A} B) : 


Derivable /\ 






(G 


1- 
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: A) : Derivable . 




cmb 


(G 


1- 


M 


: B) : Derivable if 






(G 


1- 


M 


: A) : Derivable /\ 






(G 


1- 


B 


: s) : Derivable /\ A <-> B : 


Convertible . 



endfm 

In this formalization we have avoided any arbitrary encoding of syntax with 
binders that would require nontrivial justifications. Also, we have seen that the 
first-order framework is sufficiently powerful to represent PTSs without making 
any commitments. In particular, there was no need to change the syntax nor the 
rules of PTSs to obtain a faithful representation. 
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3.2 Taking Names Seriously 

Although the abstract treatment of names in PTSs leads to a general metatheory 
that can be used as a high-level theoretical basis for quite different implementa- 
tions of PTSs, there is a price to pay, in that an abstract view necessarily limits 
the expressivity of the theory. In the case of PTSs, properties involving names 
cannot be expressed. Indeed, we often need a more concrete representation with 
more specialized results to deal, for example, with the implementation of a formal 
system, or with tools that use the formal system in an essential way. Also in the 
context of reasoning about a formal system, a more concrete specification that 
is computationally meaningful can have considerable advantages for the partial 
automation of metatheoretic proofs in logics with computational sublanguages. 

However, as soon as we take names seriously, i.e., we give up the identification 
of a-convertihle terms, and interpret the inference rules literally, we encounter 
at least two problems first discussed in [40] under the title “closure under a- 
con version”.^ 

The first problem is that the set of derivable judgements is not closed under 
a-conversion. For instance, adapting an example given for A-^- in [40], we cannot 
derive a judgement of the form 

A : Prop, P : (Z : AjProp h [X : A][X : P A] A : {X : A}{X : P AjProp, 
say in CC, although the a-equi valent version 

A : Prop, P : (Z : AjProp h [A : A] [T : P A] A : {A : A}{Y : P AjProp, 

where some bound variables are distinct can be derived. 

A second difficulty pointed out in [40] is that we want to derive 

A : Prop, P :{Z : A}Prop h [A : A][A : P A] A : {A : A}{Y : P A}(P A), 
but we should not be able to derive 

A : Prop, P :{Z : AjProp h [A : A][A : P A]A : {A : A}{A : P A}(P A). 

However, we cannot derive the first judgement, since the name A in the 
conclusion of the Lda rule is the same on both sides of the colon. 

To tackle the first problem. Pollack proposed a type system h/*, a variation 
of A-^-. It uses a more liberal notion of context that allows multiple declarations 
of the same name, the one most recently introduced being visible inside the 
judgement. Unfortunately, he did not pursue this direction further because of 
the second difficulty, which appears in the context of PTSs with dependent types 
but is not present in A-^-. Concerning h/t, he remarks “I don’t think we can do 
the same for PTS.” 

The solution finally discussed in [40] is the solution employed in the construc- 
tive engine [25] used in proof assistants such as LEGO [41] and COQ [2]. The 

® The problem with closure under a-conversion also remains unsolved in [30], where 
a system with dependent types is presented that does not enjoy this property. 
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idea is to use a hybrid naming scheme which employs distinct names for global 
variables declared in the context of a judgement, and a de Bruijn representation 
of terms with bound local variables. Clearly, PTSs based on such a hybrid nam- 
ing scheme are a correct implementation of (abstract) PTSs as described above. 
More precisely, PTSs using the hybrid naming scheme can be seen as particular 
models of the MEL specification of PTSs in the sense that the corresponding 
model is isomorphic to the one given by the appropriately instantiated functional 
module PTS. Nevertheless, an approach which maintains a distinction between 
global and local variables appears not to be very uniform, complicating formal 
metatheoretic proofs and type checking. Of course, scaling up Pollack’s h/t to 
PTSs would be much more satisfying, and this is the direction we pursue in the 
following. 

3.3 Indexed Names and Named Indices 

We believe that the root of the second difficulty discussed above is that the tradi- 
tional notion of binding used in logic and in programming reveals an undesirable 
property, which may be called accidental hiding^ if the language is refined in the 
most direct way, i.e., by just giving up identification by n-conversion. 

Consider for instance the formula 

yx .{A A VY .{B^yx . C{X))) 

with distinct names X and Y, where C{X) is a formula that contains X free. 
Each occurrence of X in C{X) is captured by the inner V quantifier, so that the 
outermost V quantifier is hidden from the viewpoint of C{X). Indeed there is no 
way to refer to the outermost V quantifier within C{X). 

Hence, we are faced with the following problem: a calculus without a-equality 
is not only less abstract, which is an unavoidable consequence of giving up identi- 
fication by a-conversion, but also, depending on the (accidental) choice of names, 
visibility of (bound) variables may be restricted. It is important to emphasize 
that visibility is not restricted in the original calculus with a-equality, since 
renaming can be performed tacitly at any time. 

Clearly, this phenomenon of hiding that occurs in the example above is 
undesirable^, because it is not present in the original calculus with a-equality. It 
is merely an accident caused by giving up identification by a-conversion without 
adding a compensating flexibility to the language. 

This suggests tackling this general problem by migrating to a more flexible 
syntax, where we express a binding constraint by annotating each name X with 
an index f G M, written Xi, that indicates how many Af -binders should be 
skipped before we reach the one that Xi refers to. For instance we write 

yx .{A A VP . (B ^ VWC'(Xo))) 

to express that Xq is bound by the inner V, and 

yx .{A A VP . (H ^ yx.c{Xi))) 

^ Of course, in general hiding is important but it is not an issue of binding; it should 
be treated independently. 
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meaning that Xi is bound by the outermost V. To make the language a conser- 
vative extension of the traditional notation, we can identify X and Xq. 

In fact, the use of indexed names is equivalent to a representation introduced 
by Berkling [7,8] in the context of A-calculus® which is why we refer to the 
notation based on indexed names also as Berkling’s notation. As indicated by 
the example above we use Berkling’s representation not (only) for A-calculus but 
as the core syntax of CINNI, the Calculus of Indexed Names and Named Indices 
which is generic in the sense that it can be instantiated for a wide range of object 
languages with different binding constructs. For a detailed treatment of CINNI, 
its metatheoretic properties, and its relation to other calculi we refer to [47,48]. 

Obviously, there is some similarity to a notation based on de Bruijn indices 
[18] . But notice that there is an essential difference: the index m in the occurrence 
Xm is not the number of binders to be skipped; it states that we have to skip m 
binders for the particular name X, not counting binders for other names. Still 
a formal relationship to de Bruijn’s notation can be established: if we restrict 
ourselves to terms that contain only a single name X, then we can replace each 
Xi by the index i without loss of information and we arrive at de Bruijn’s purely 
indexed notation.® In other words, if we restrict the available names to a single 
one, we obtain de Bruijn’s notation as a very special case. In this sense, Berkling’s 
representation can be formally seen as a proper generalization of de Bruijn’s 
notation. Pragmatically, however, the relationship to de Bruijn’s syntax plays 
only a minor role, since a typical user will exploit the dimension of names much 
more than the dimension of indices. Hence, in practice the notation can be used 
as a standard named notation, with the additional advantage that accidental 
hiding and weird renaming^ are avoided. 

The pragmatic advantage of Berkling’s notation is that it can be used to 
reduce the distance between the formal system and its implementation: it can 
be directly employed by the user who wants to think in terms of names, so 
that the need for a translation between an internal representation (e.g. using 
de Bruijn indices) and a user-friendly syntax (e.g. using ordinary names) dis- 
appears completely. As far as we know the CINNI substitution calculus is the 
first calculus of explicit substitutions which combines named and index-based 
representations and hence provides a link between these two worlds of explicit 
substitution calculi. 

Usually, this translation is not considered to be a problem, and indeed in the 
case of terms, where all parts are known or accessible, solutions are straightfor- 
ward. However, it is clear that this gap is not desirable: consider, for example, a 
tactic-based theorem prover where the user is confronted with an internal rep- 
resentation which reflects the theory only in a very indirect way. More seriously, 
the translation between internal and external representations becomes unwork- 
able, or at least requires certain restrictions, as soon as we use terms containing 

® An indexed variable Xi is represented in Berkling’s representation as where H 
is the so-called unbinding operation. 

® With the slight difference that de Brnijn’s indices start at 1 instead of 0. 

^ See the discussion on weird renaming in the next section. 
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metavariables, holes or placeholders, which are useful for many applications in- 
cluding unification algorithms and representation of incomplete proofs. 



3.4 Explicit Substitutions 

In the previous section we discussed Berkling’s first-order representation for ex- 
pressions, which contains the conventional named notation as well as de Bruijn’s 
indexed notation as special cases. The most important operation to be performed 
on such terms represented in this way is capture-free substitution. Therefore, we 
now present the CINNI substitution calculus, a first-order calculus that can be 
seen as an (operational) refinement of an external (i.e. metalevel) substitution 
function such as the one given in [8] . 

Strictly speaking, CINNI is a family of explicit substitution calculi, parame- 
terized by the syntax (including information about binding) of the language we 
want to represent. Here we present the instantiation of this substitution calculus 
for the untyped A-calculus. A-terms in CINNI syntax are: 

Xra \{M N)\ [X]M 

As a motivation for the substitution calculus given below, consider the fol- 
lowing example of a /3-reduction step in the traditional A-calculus with distinct 
names X and Y, again taking names literally, i.e. not presupposing identification 
by a-conversion: 

{{[X][Y]X)Y) ^ [Z]Y 

Clearly, Z must be a name different from Y to avoid capturing. Unfortunately, 
there is no canonical choice if all names should be treated as being equal. We call 
this phenomenon weird renaming of bound variables. It is actually a combination 
of two undesirable effects: (1) names that have been carefully chosen by the user 
have to be changed, and (2) the enforced choice of a new name collides with the 
right of names to be treated as equal citizens. 

These effects are avoided in the CINNI calculus, when instantiated to the 
A-calculus. CINNI is specified by the first-order equational theory given below. 
Indeed, the only operation assumed on names is equality. CINNI has also an 
operational semantics viewing equations as rewrite rules. Apart from the two 
basic kinds of substitutions, namely simple substitutions [X-.=M], and shift sub- 
stitutions tjf, substitutions can be lifted using 'flx5', where the variable S ranges 
over substitutions. 



[X-.=M] Xo = M 


txSXo = 


[X:=M] X^+i = X^ 


tlx -S' Xm+1 


[X-.=M] = y„ if A ^ y 


txSY„ = 


'IxXm = Xm+1 


S {MN) = 


rxY„ = Y^ifX^Y 


S {[X]M) 



Xo 

= lx {S Xm) 

U {S Y„) ifX^Y 

(SM){SN) 

= [X]{iixSM) 
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The CINNI calculus can be instantiated to various object languages with 
different binding operators to give a more concrete treatment of their associated 
formal systems. The only equations specific to the syntax of the language are 
the structural equations. Here, the last two equations in the right column are 
the structural equations for the A-calculus. In a similar way, CINNI can be 
instantiated to other object languages such as Abadi and Cardelli’s c-calculus 
or Milner’s 7r-calculus [47,48]. 

Now we can define f3-reduction by the rule 

{[X]N)M ^0 [X:=M]N. 

Notice that weird renaming of bound variables as in the previous example is 
avoided with the new notion of /J-reduction which yields® 

(([x][r]Ao)Fo) ([F]yi) 

As another application of substitution, consider renaming of a hound variable 
A by • as in the following rule of a-reduction: 

([A]iV) ([.][A:=.j T.A) ifAy^. 

where • is an arbitrary but fixed name. Using this rule every CINNI term can 
be reduced to a nameless a-normal form which is essentially its de Bruijn index 
representation. For terms M,N we use M =„ N to denote that M and N are 
equal up to renaming of bound variables. 

Just as Berkling’s notation contains de Bruijn’s indexed notation as a very 
special case, the instantiation of CINNI for the A-calculus reduces to the calculus 
Xv of explicit substitutions proposed by Pierre Lescanne [27,28,5], but only in 
the degenerate case where we only use a single name. It is noteworthy that 
Xv is the smallest known indexed substitution calculus enjoying good theoretic 
properties like confluence® and preservation of strong normalization. It seems 
that its simplicity is inherited by CINNI although in practice the dimension of 
names will be much more important than the dimension of indices. Hence, we 
tend to think of CINNI more as a substitution calculus with names than as one 
with indices. 

3.5 Uniform Pure Type Systems 

The application of CINNI to PTSs can be seen as Pollack’s h/* scaled up to PTSs. 
In contrast to the hybrid approach to PTSs adopted in the constructive engine 
[25] and in the PTS formalization given in [34] based on an idea from [15], both 

® One might argue that even the change of variable indices constitutes a form of 
renaming, but an important point is that only references to previously introduced 
names are affected rather than the binding occurrences themselves. 

® In fact, we have confluence on terms without metavariables [47,48], but this is suf- 
ficient for the approach to type checking/inference presented in this paper, since all 
metavariables will eventually become instantiated. 
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distinguishing between global and local variables, we use indexed names uni- 
formly. This suggests defining uniform pure type systems (UPTSs) by modifying 
PTSs in three steps: 

First, PTS terms are generalized to UPTS terms in the way explained before, 
i.e., UPTS terms are defined by the first-order CINNI syntax: 

Xm \{M N)\[X : A]M \ {X : A}M \ s 

As a second step, we adapt the syntax-dependent part of the CINNI calculus 
to UPTS terms: 



S s = s 

S (MN) = (SM){SN) 

S{[X:A]M) = [X:{SAmxSM) 

S ({A : A}M) = {X:{S M) 



The third and final step is to define the derivable typing judgements. Since 
we do not want to identify a-convertible terms, this is a fundamental change 
in the formal system. However, a careful inspection of the typing rules under 
the new reading shows that only minor changes in the rules Start and Weak are 
needed. The new rules are: 



T h A : s 

r,A : Ah Ao : TxA 



(Start) 



Ph M : A Ph B -.s 
r,X:BhUM :TjcA 



(Weak) 



It might appear that the UPTSs we have defined above are a specialization 
of PTSs, since we have committed ourselves to a particular representation of 
names. But this is not the full truth, because on the other hand we have de- 
scribed a generalization of PTSs where multiple declarations of the same name 
are admitted in a well- typed context. Notice that in both rules above we have 
dropped the side condition X ^ P, which means that we have completely elimi- 
nated the need for these side conditions in UPTSs. We would also like to point 
out, that, in particular, we have not touched the Lda rule: the only place where 
a-conversion comes into play is in the Conv rule, where =f} subsumes a- and 
/3-conversion, just as in the original PTSs. 

Finally, we describe how these changes are reflected in the MEL specification, 
that is how UPTSs can be represented by modifying the previous specification. 

First, instead of using names as variables we use indexed names. So we replace 
subsort Qid < Var by 



op _{_} : Qid Nat -> Var . 

Second, instead of conventional substitution [_: =_] _, we use CINNI for UPTS 
terms: 
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sort Subst . 

op [_:=_] : Qid Trm -> Subst . 
op [shift_] : Qid -> Subst . 

op [lift ] : Qid Subst -> Subst . 

op : Subst Trm -> Trm . 

var S : Subst . 

vars n m : Nat . 

eq ([X := M] (X{0») = M . 

eq ([X := M] (X{suc(m)})) = (X{m>) . 

ceq ([X := M] (Y{n») = (Y{n» if X =/= Y . 

eq ([shift X] (X{m})) = (X{suc(m)}) . 

ceq ([shift X] (Y{n})) = (Y{n}) if X =/= Y . 

eq ([lift X S] (X{0})) = (X{0}) . 

eq ([lift X S] (X{suc(m)})) = [shift X] (S (X{m})) . 

ceq ([lift X S] (Y{m})) = [shift X] (S (Y{m>)) if X =/= Y . 

eq (S s) = s . 

eq (S (M N)) = ((S M) (S N)) . 

eq S ([X : A] M) = [X : (S A)] ([lift X S] M) . 

eq S ({X : A} M) = {X : (S A)} ([lift X S] M) . 

Third, conversion now explicitly contains a-conversion, something that was 
implicit in the equality of the previous specification: 

mb [X : A] M <-> 

[Y : A] ([X := Y{0}] [shift Y] M) : Convertible . 
mb {X : A} M <-> 

{Y : A} ([X := Y{0}] [shift Y] M) : Convertible . 

Finally, the new versions of Start and Weak are: 

cmb (G,(X : A) |- X{0} : [shift X] A) : Derivable if 
(G |- A : s) : Derivable . 

cmb (G,(X : B) |- [shift X] M : [shift X] A) : Derivable if 
(G I - M : A) : Derivable /\ 

(G |- B : s) : Derivable . 

Again, we can see that the representational distance between the mathemat- 
ical presentation of UPTSs and their MEL specification is practically zero. In 
particular, the equational nature of the CINNI substitution calculus is directly 
captured by the MEL specification. 
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UPTSs are more liberal than PTS, since a derivable judgement F \- M : A 
may contain multiple declarations of the same name in F. However, the set of 
derivable judgements F \- M : A oi PTS can be recovered as the set of derivable 
UPTS judgements F \~i M : A generated by adding the following rule: 



Fh M -.A 
FhiM : A 



if F is simple 



(Simple) 



The representation of judgements F \~i M : A together with this rule in MEL 
is straightforward, and we omit it here and in all the following formalizations 
for the sake of brevity. 

To state the following results we proceed as for PTSs: We extend a-conversion 
=a from terms to judgements, so that F \- M : A =„ T' h M' : A' iff F' h M' : 
A' and F \- M : A are equal up to consistent renaming of declared and bound 
variables. Then we have the following 



Lemma 32 (Strong Closure under a- Conversion for UPTSs) 

Let M, A, M', A! be UPTS terms and T, F' be UPTS contexts. If the UPTS 
judgement F \- M : H is derivable in UPTS 5 and F \- M : A =a F' h M' : A' , 
then F' h M' : A! is derivable in UPTSg. 

Proof Sketch. By induction over derivations oi F \- M ■. A. □ 

It is noteworthy that a weak form of this lemma using a-conversion on terms 
instead of judgements, i.e. the special case where F = F' , cannot be proved 
directly by induction. The induction would fail for the rules Pi and Lda, since a 
declared variable X becomes a local variable. 

As for PTSs the previous lemma is equivalent to the admissibility of the 
following rule in UPTSs: 

r \- M ■ A 

— 7 - — — jT a F \- M : A =a F' h M' : A' (Rename) 

r' h M' : A' ^ ' 

Using the terminology introduced in Section 1.1 for entailment systems, each 
of the following two propositions establishes a sound and complete total corre- 
spondence of the form PTSs ^ UPTSs, where S is an arbitrary PTS signature. 



Proposition 33 (Soundness and Completeness of UPTSs I) 

For all PTS terms M,A and PTS contexts F, if the PTS judgement F \~i M : A 
is derivable in UPTSs then F \- M : A is derivable in PTSs and vice versa.^° 

Proof Sketch. 

First observe that each PTS rule is a UPTS rule if we restrict ourselves to 
simple judgements. In particular, the side conditions A G U in the PTS rules 
Start and Weak imply that the shift substitution in the corresponding UPTS 
rules can be eliminated. 

(=>) Given a UPTS derivation of a simple judgement F \- M : A, each 
occurrence of a UPTS inference rule can be replaced as follows: First the original 



10 



Here we make use of the convention, introduced in Section 3.3, that ordinary terms 
(here PTS terms) can be seen as CINNI terms (here UPTS terms). 
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premises are converted into suitable simple PTS form by virtue of Rename. Then 
the corresponding inference rule for PTSs is applied (which is also a UPTS 
rule according to the observation above). Finally, the conclusion in simple PTS 
form is converted back to the original conclusion in UPTS form, again using 
Rename. After transforming the entire derivation in this way all intermediate 
UPTS judgements which are not PTS judgements, i.e. the original premises and 
original conclusions, can be removed, and the result is still a UPTS derivation. 
Also, the resulting derivation corresponds to a derivation in PTSs extended by 
the admissible rule Rename. 

( 4 =) According to the observation above, each application of a PTS rule can 
be seen as an application of the corresponding UPTS rule. Furthermore, each 
implicit a-conversion step that is possible in PTSs can be simulated by Rename, 
which is an admissible rule in UPTSs. 

□ 

In other words, UPTSs are conservative over PTSs. A slightly weaker but 
more comprehensive correspondence of the form PTSs UPTSs can be given 
modulo renaming of variables: 

Proposition 34 (Soundness and Completeness of UPTSs II) 

For all UPTS terms M,A, PTS terms M' , A' , UPTS contexts F and simple PTS 
contexts F' with F \- M : A =„ F' h M' : A' , if the UPTS judgement F h 
M : A is derivable in UPTSs then F' h M' : A' is derivable in PTSs and vice 
versa. 

Proof Sketch. 

(=^) Let F h M : A he derivable in UPTSs and let F h M : A =a F' h 
M' : A' . By Proposition 32 (strong a-closure) F' h M' : A' and therefore F' \-\ 
M' : A' are derivable in UPTSs- So by Proposition 33 F' h M' : A' is derivable 

in PTSs- 

( 4 =) Let F' h M' : A' be derivable in PTSs and let F' h M' : A' =a F h M : 
A. By Proposition 33, F' h M' : A' is derivable in UPTSs, and by Proposition 
32 (strong a-closure) F \- M ■. A is derivable in UPTSs too. 

□ 

The last proposition implies that, concerning judgements of the form F \- M : 
A, PTSs and UPTSs are equivalent modulo a-conversion. Hence all (metatheo- 
retic) results about PTSs [22] apply to UPTSs after appropriate renaming. 

Another consequence of the last proposition is that the new form of judge- 
ment F \- 1 M : A is not necessary to ensure soundness, and could therefore be 
dropped. Sometimes, however, focusing on judgements of the form F \~i M : A 
instead of the more general form F \- M : A is more convenient, e.g. to formulate 
the weakening/ thinning lemma [22,52], since simple contexts can be treated as 
sets of declarations. 

3.6 A Conservative Optimization 

The presentations of PTSs and UPTSs given above maintain a good economy in 
the number of rules and are therefore well-suited for metatheoretic (inductive) 
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reasoning. The judgement F \- M \ A implicitly subsumes another judgement 
r Ih, stating that T is a well-typed context. Since in practice checking contexts is 
as important as checking types, we switch to a conservative extension of UPTSs 
(similar to an optimization for PTSs mentioned in [52]) that is not biased towards 
any of the two forms of judgement. From a practical point of view, the addition 
of a separate judgement for well-typed contexts can be seen as an optimization 
which avoids rechecking contexts in each subderivation. We will refer to this 
optimized version as optimized UPTSs (OUPTSs) and the entailment system 
will be denoted by OUPTS. The only modifications we need are described 
below. In addition to the main typing judgement, which is written now as P Ih 
M : A (stating that M is an element of the type T in T), we use context typing 
judgements of the form P Ih meaning that T is a well-typed context, and relative 
typing judgements of the form P \- M : A meaning that M is an element of type 
if T is well-typed. Furthermore, we add the following rules: 



[]l^ 



(Ctxtl) 



F Ih Ph A-.s 
P,X :A\h 

Pi_ y ; — ; V \ if lookup (P,Xm) is defined 

r\- Xm'- lookup (P, Xjn) 

F Ih Ph M : A 

TTJTTa 

where lookup{P,Xm) is a partial function defined by: 



(Ctxt2) 

(Lookup) 

(Main) 



lookup{{P, X : A),Xo) = jxA 
lookup{{P,X : A),Xm+i) = j xlookup{P, Xm) 

lookup{{P,X : A),Ym) = j x lookup (P,Ym) if X yf F 



Then we replace Ax and Simple by: 



F h Si : S2 



(si, S2) G A 



(Ax) 



Flh M : A 
PYiM : A 



if no variable is declared in F more than once. 



(Simple) 



respectively, and we remove the rules Start and Weak, since they are admis- 
sible rules in the new system. The system we have just obtained is similar to the 
system \~vtyp, ^vcxt presented in [52], but here we are concerned with UPTSs 
instead of PTSs. Another minor difference is that we make use of an explicit 
lookup function. As before, we do not need any freshness side conditions thanks 
to CINNI. 

Again, the representation in MEL is quite direct. It nicely illustrates the 
mixed specification style using equations and memberships, and also the repre- 
sentation of partial functions such as lookup. 




356 Mark-Oliver Stehr and Jose Meseguer 



sort Trm? . 
subsort Trm < Trm? . 

op lookup : Context Var -> Trm? . 
eq lookup (G,(X : A), X{0}) = [shift X] A . 

eq lookup (G,(X : A), X{suc(m)}) = [shift X] lookup (G,X{m}) . 

ceq lookup(G,(X : A), Y{m}) = lookup(G,Y{m}) if (X =/= Y) . 

op _ I I - : Context -> Judgement . 

op _ I _ : Context Trm Trm -> Judgement . 

op _l : Context Trm Trm -> Judgement . 

mb (emptyContext I |-) : Derivable . 

cmb (G,(X : A) I |-) : Derivable if 

(G I |-) : Derivable /\ (G |- A : s) : Derivable . 

cmb (G |- X{m} : lookup (G, X{m}) ) : Derivable if 
lookup (G,X{m}) : Trm . 

cmb (G I I - M : A) : Derivable if 

(G I |-) : Derivable /\ (G I - M : A) : Derivable . 

cmb (G |- si : s2) : Derivable if (sl,s2) : Axioms . 

OUPTSs are equivalent to UPTSs, i.e., there is a sound and complete total 
correspondence of the kind UPTSs r\ OUPTSs for arbitrary PTS signatures 
S , in the following sense: 

Proposition 35 (Soundness and Completeness of OUPTSs) 

Let M,A be UPTS terms, and let T be a UPTS context. If the judgement T Ih 
M : A {r \\~i M : A) is derivable in OUPTSs, then F \- M : A {F \~i M : A) is 
derivable in UPTSs and vice versa. 

Proof Sketch. It is easy to adopt the proof of the similar lemma 23 in [52] to 
our setting. The main change is that we are using UPTSs instead of PTSs here. 
A minor point is that we are using an explicit lookup function. □ 

4 The Meta-operational View of PTSs 

PTSs can not only be equipped with a logical semantics, e.g. via the proposition- 
as-types interpretation, but, more fundamentally, PTSs are usually equipped 
with an operational semantics, defined by an internal notion of functional com- 
putation, such as /3-reduction. The operational view of PTSs is concerned with 
their internal notion of computation, but here we are interested in the meta- 
operational view, which deals with the question of how to embed PTSs in a formal 
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system with an operational semantics, so that typical computational tasks like 
type checking and type inference become possible by exploiting the operational 
semantics of the metalanguage. In the following we employ for this purpose the 
efficiently executable sublanguage of rewriting logic that is supported by the 
Maude engine. 

First, we introduce several well-known classes of PTS signatures, giving rise 
to corresponding PTSs that are practically interesting and enjoy particularly 
good properties. 

Definition 41 A PTS signature S is decidable iff: (1) 5 is denumerable, (2) A 
and TZ are decidable, and (3) for all si,S2 G S the predicates 3s2 : (si,sy G A 
and 3sg : (si, S2, Sg) G TZ are decidable. 

Decidability is a reasonable requirement to ensure that type inference and 
type checking do not become undecidable because of a too complex PTS signa- 
ture. 



Definition 42 A PTS signature S is functional iff (1) (si,S2) G A and 
(si, S2) G A implies S 2 = s' 2 , and (2) (si, S2j S3) G TZ and (si, S2, Sg) G TZ implies 

S3 = s'g. 

In functional PTS signatures, the relations A and TZ can be viewed as partial 
functions A : 5 ^ 5 and TZ : S x S ^ S. Functionality ensures that every term 
has a unique type modulo =/3 [22]. The class of functional PTSs^^ includes, for 
example, all systems of the A-cube. 

Definition 43 A PTS signature S is full iff for all si, S2 G S there is an S3 such 
that (si,S2,S3) G TZ. A PTS signature S is semi-full iff (si, 82,53) G TZ implies 
that for each S2 there is an Sg such that (si, S2, s'^) G TZ. 

Full PTSs allow us to form dependent types {X : A}B very liberally, by 
avoiding those restrictions on the sorts of A and B that are imposed by the side 
condition (si, S2, S3) G TZ of the Pi rule. As an example, CC is a full PTS. 



Definition 44 Given a PTS signature S, a top sort is a sort s such that there 
is no sort s' with (s, s') G A. The set of top sorts is denoted by 5top. 



To avoid inessential technicalities in our presentation, we will later focus on 
PTS signatures without top sorts, which introduce some kind of nonuniformity 
in the set of sorts. Just as TZ can be seen as a function TZ : S x S ^ S in full 
PTS signatures, A can be viewed as a function A : 5 ^ 5 in functional PTS 
signatures without top sorts. 

Semi-full PTSs have the nice property that we can get rid of the third premise 
in Lda by replacing it with the following rule: 



BG A: Si r,X ■. AG M ■. B 
BG[X : A]M : {X : A}B 



(si,S2,sg) G TZ and B ^ 5top 



(Lda’) 



11 



The attributes for PTS signatures are naturally lifted to the corresponding PTSs. 
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The premises together with the side conditions in Lda’ imply that {X : A}B is 
a type (cf. rule Pi). Indeed, as explained in [52] in the context of PTSs, replacing 
Lda by Lda’ does not change the set of derivable judgements in semi-full UPTSs. 

For full UPTSs without top sorts we can completely eliminate the side condi- 
tions in the rule Lda', and we obtain Lda" without changing the set of derivable 
judgements: 

rh A: s r,X : Ah M : B 

Bh[X : A]M : {X : A}B ^ ^ ’ 

Our example PTS signature of CC at the beginning of Section 3 has Type as 
a top sort. However, it is straightforward to extend CC by an infinite universe 
hierarchy yielding a PTS without top sorts. Our example PTS signature of CC 
has Type as a top sort. However, it is straightforward to extend CC by an infinite 
universe hierarchy yielding a PTS without top sorts. 

Together with the introduction of UPTSs in the previous section, we have 
now (following the corresponding arguments for PTSs in [52]) three families of 
inference systems which only differ in the choice of the rule Lda. For a full PTS 
signature S without top sorts all of them define the same unary entailment 
system, which is denoted by UPTSs. 

In the remainder of this paper we will present a standard type checking 
algorithm for a class of UPTSs using rewriting logic as a formal specification 
language. In spite of some unsolved theoretical questions such as the expansion 
postponement problem, efficient algorithms for the important classes of func- 
tional PTSs and semi-full PTSs (satisfying appropriate decidability and nor- 
malization properties) have been presented in [52]. In order to avoid excessive 
technical details and to make clear the general way we use rewriting logic to rep- 
resent type checking algorithms, we restrict ourselves in the following to UPTSs 
that are decidable, normalizing (w.r.t. /3-reduction), functional, full, and with- 
out top sorts. The class of UPTSs that are decidable, normalizing, functional 
and semi-full can be treated along the same lines (using the rule Lda’ instead of 
Lda" ). 

The use of UPTSs instead of PTSs is motivated by our desire to obtain 
a formal executable representation that takes names seriously and makes type 
checking simpler and more uniform. The approach is different from the construc- 
tive engine [25] and its presentation in [40] that employs named global variables 
and a de Bruijn representation for local variables. It is also different from [15], 
[52] and the formalization [34] that distinguish between two unrelated sets of 
global names and local names. 

4.1 Uniform PTSs in Membership Equational Logic 

The standard way to implement type checking, which goes back to [33] and 
[25], is to cast the inference rules into an equivalent syntax-directed inductive 
definition, and to define a type-inference function on the basis of this new system. 
Formally and technically this could be done in the executable sublanguage of 
MEL or in any other functional programming language, but the use of MEL is 
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attractive, since it allows us to formulate the logical and operational versions of 
PTSs in a single uniform language with a simple semantics, which in particular 
does not presuppose higher-order constructs, but is used to explain them in more 
elementary terms. Also, data structures and functions of the specification can 
be directly used in the implementation. 

In our setting there is another reason why MEL is more natural than the 
use of a (higher-order) functional programming language: the equational spec- 
ification of the calculus of substitutions presented above is naturally equipped 
with an operational semantics just by viewing the equations as rewrite rules. By 
contrast, in a functional programming language that is not based on equational 
rewriting, the substitution calculus has to be encoded, which essentially means 
that a (specialized) rewrite engine for this calculus has to be implemented in the 
functional language itself and, what is even more cumbersome, this engine has 
to be explicitly invoked when needed. In this sense, a specification/programming 
style based on rewriting is more abstract and closer to mathematical practice 
for applications of this kind than a (higher-order) functional programming ap- 
proach. 

Using the specification of the above substitution calculus, a purely equational 
executable specification of a type checker for UPTSs with decidable type check- 
ing can be written in MEL using standard equational/functional programming 
techniques. The core of this specification consists of a type-inference function 

op type : Context Trm -> Trm? . 

that computes a type for each term which is well- typed in the given context. 
The function can be defined in a way similar to the one given in [45], but using 
CINNI, instead of abstracting from the treatment of names. 

Thanks to CINNI, freshness conditions are avoided. Therefore, an implemen- 
tation based on this specification appears to be more elegant than that of the 
constructive engine with its hybrid treatment of names. As an additional advan- 
tage, multiple declarations of the same name are naturally admitted in contexts 
if we use judgements F \\- M ■. A. However, it is also easy to disallow these more 
general contexts if desired by implementing simple judgements F \\~i M \ A. 

Instead of discussing this purely equational approach in more detail, we 
present an alternative approach in the following section that exploits features 
of rewriting logic that are beyond equational and functional languages. Our ex- 
perience shows that this alternative approach scales up well to more complex 
type theories, e.g. extensions of UPTSs such as OCC (see Section 5.1) in a more 
satisfactory way than the purely functional and equational approaches to type 
checking. 

4.2 Uniform PTSs in Rewriting Logic 

As shown by an extensive collection of examples in [31,32], rewriting logic can 
be used as a logical framework that can naturally represent inference systems 
of different kinds in a logically and operationally satisfying way. In the present 
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section we view a type checker as a particular inference system. In contrast to 
a (higher-order) functional programming approach that would require us to en- 
code the inference system in terms of a type checking function, the rewriting 
logic approach offers the advantage that inference rules can be expressed di- 
rectly, namely, as rewrite rules. We will in fact make use of a type inference 
system expressed as a collection of rewrite rules that transform a conjunction 
of judgements into a simplified form, in the style of constraint solving systems. 
This yields a rewrite system that is efficiently executable, while still maintaining 
a close correspondence to the logical specification of UPTSs. 

The rewriting logic specification represents rewriting-based OUPTSs 
(ROUPTSs) and is able to perform type checking, i.e. to decide derivability of 
judgements of the form T Ih, T h M : A, and P Ih M : A, for the class of 
decidable, normalizing, functional, full and PTS signatures without top sorts 
discussed before. As in PTSs, type checking is reduced to type inference, that 
is, to solving incomplete queries of the form P \- M ->: 1. 

Instead of giving an informal account we directly discuss the formal specifi- 
cation in rewriting logic. 

First, we exploit our assumption that the PTS signature is decidable, func- 
tional, full and without top sorts, which means that the relations A and TZ can 
be specified by equationally-defined functions Axioms and Rules: 

fth FPTS-SIG is 

sort Sorts . 

op Axioms : Sorts -> Sorts . 

op Rules : Sorts Sorts -> Sorts . 

endfth 

As usual for syntax-directed approaches following the ideas of [33] and [25] we 
“invert” the inference rules in order to obtain a goal-directed algorithm from the 
inductive definition. In contrast to a purely equational and functional approach, 
the rewriting logic specification we aim at has a rewrite transition system as a 
model, and can therefore be seen as an operational generalization of the equa- 
tional and functional paradigms. In contrast to [52] and [40], the type-checking 
algorithm itself receives a direct formal status as a transition system, which is 
a good basis for reasoning formally about operational properties and especially 
about its correctness. 

The inductive definition of UPTSs can be seen as a static description of a 
set of judgements that we would like to equip with a dynamic structure. More 
precisely, a (static) logical implication 

A\ A ... A An B 

can be seen as an inference rule or (dynamic) state transition refining a goal B 
into subgoals Ai, , A„, and can be directly represented as a rewrite rule 



B ^ Ai A ... A An 
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in rewriting logic. Each state consists of a finite set of subgoals that remain to 
be solved. 

The static description can be seen as inducing the following invariant that 
our dynamic system should always satisfy: for each state, the empty set of goals 
is reachable iff the logical interpretation of the state is true. 

Although the inference rules of a formal system typically take the form of 
Horn clauses that can be operationally refined to rewrite rules, there may be 
functional and equational parts (e.g. auxiliary functions or substitution calculi) 
that are more naturally expressed in the MEL fragment. It is this mix of different 
paradigms that allows us to express the type-checking algorithm in a way that 
is very close to the logical specification. 

We discuss below the rewriting logic specification of the UPTS type checker in 
some detail. Instead of an equational theory introduced by the fmod keyword, the 
specification takes the form of a rewrite theory, introduced by the mod keyword, 
that has a transition system as its initial semantics: 

mod PTS[S :: FPTS-SIG] is 

We reuse most components of the functional module defined before, but in 
addition to the typing judgement 

op : Context Trm Trm -> Judgement . 

we add the following auxiliary judgements: 

op _Sort : Trm -> Judgement . 

op (_,_,_)Rule : Trm Trm Trm -> Judgement . 

op _=_ : Trm Trm -> Judgement . 

op : Trm Trm -> Judgement . 

op _ I : _ : Context Trm Trm -> Judgement . 

op : Context Trm Trm Trm Trm Trm -> 

Judgement . 

Recall that, in our setting of PTS signatures without top sorts, T is a type 
in T iff T h T : s. Presupposing that T is a well-typed context and A,B are 
types in F, the meaning of the auxiliary judgements is the following: The judge- 
ment A Sort means that there is an s G 5 such that A =jj s. The judgement 
(A, B, s) Rule means that there are Si, S2 & S such that A si, B S2 and 
(si,S2,s) G TZ. The judgement A <-> B just means that A =p B. The judge- 
ment r \- M ->: T means that M has an inferred type T in F. Regarding this 
refinement of typing judgements we only assume that F \- M ->: T implies F h 
M : T, and conversely that F \- M : T implies that T T' and F \- M ->: T' 
for some T'. Furthermore, the judgement F h ((M ->: S){N ->: T)) ->: U 
abbreviates F \- M -> : S, F \- N ->: T, and F h (M N) -> : U. Finally, the 
judgement M = N just means that M and N are equal terms. 

In order to express intermediate goals or queries, like F \- M ->: ?, that are 
present in the operational refinement but not in the abstract presentation, we 
extend terms by explicit metavariables: 
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sort MetaVar . 
subsort MetaVar < Trm . 
op ? : Qid -> MetaVar . 
var MV : MetaVar . 

In ROUPTSs we use the weak head normal form, calculated by the following 
function whnf , to check if two terms are convertible, and in particular if a term is 
convertible to the form s or {X : A}M . We also use sorts WhNf and WhReducible 
containing terms in weak head normal form and weak head reducible terms, 
respectively. 

sort WhNf WhReducible . 
subsort WhNf < Trm . 

subsort Sorts < WhNf . 

subsort Var < WhNf . 

mb ([X : A] M) : WhNf . 

mb ({X : A} B) : WhNf . 

mb (s N) : WhNf . 

mb (X{m> N) : WhNf . 

cmb ((P Q) N) : WhNf if (P Q) : WhNf . 

mb (({X : A} M) N) : WhNf . 

subsort WhReducible < Trm . 

mb (([X : A] M) N) : WhReducible . 

cmb (M N) : WhReducible if M : WhReducible . 

op whnf : Trm -> Trm? . 

ceq whnf (M) = M if M : WhNf . 

eq whnf(([X : A] M) N) = whnf ( [X ;= N] M) . 

ceq whnf (M N) = whnf (whnf (M) N) if M : WhReducible . 

A configuration is a conjunctive set of judgements that have to be solved or 
verified by the type checker. We represent a set of judgements as a list. This 
allows us to solve goals in a well-defined order, a fact that we exploit later in 
this section. 

sort JudgementList . 

op emptyJudgementList : -> JudgementList . 
subsort Judgement < JudgementList . 

op : JudgementList JudgementList -> JudgementList 

[assoc id: emptyJudgementList] . 

var JS : JudgementList . 
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sort Configuration . 

op {{_}} : JudgementList -> Configuration . 

Replacement of metavariables by terms (that is, textual replacement) has the 
obvious definition, not spelled out here, except for its syntax: 

op : MetaVar Trm Trm -> Trm . 

op : MetaVar Trm Subst -> Subst . 

op : MetaVar Trm Context -> Context . 

op <_ : =_>_ : MetaVar Trm Judgement -> Judgement . 

op : MetaVar Trm JudgementList -> JudgementList . 

It is used only in the following equality elimination rule, that instantiates a 
metavariable throughout the entire configuration if it is uniquely determined by 
an equality: 

rl [Subst] : {{ (MV = A) JS }}=>{{< MV := A > JS » . 

A rule like this is typical of a constraint-based programming approach, and 
indeed the configuration can be seen as a set of constraints that should be 
simplified using the subsequent rules [32]. 

In addition to simplification of constraints by rewrite rules, simplification by 
equational rewriting also plays a major role in our approach. As an example, 
the judgement of convertibility between normalizing terms can be checked using 
whnf as follows. In order to avoid redundant reductions we reduce the general 
problem to a check of convertibility between weak head normal forms (which are 
treated by the first five rules below) . In the case of binders we perform renaming 
to equalize names. 



rl 


[Convl] : 


{{ 


rl 


[Conv2] : 


{{ 


crl 


1 1 
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if 


rl 


[Conv4] : 


{{ 






{{ 


rl 


[ConvS] : 


{{ 






{{ 



(s <-> s) JS ]•]• => {{ JS . 

(X{m> <-> X{m>) JS }} => {{ JS }} . 

((M N) <-> (M’ N’)) JS }} => 

(M <-> MO (N <-> NO JS » 

(M N) : WhNf /\ (M’ NO : WhNf . 

({X : A} T <-> {Y : AO TO JS }} => 

(A <-> AO 

([X := Y{0}] [shift Y] T <-> TO JS }} . 

([X : A] M <-> [Y : A’] MO JS }} => 

(A <-> AO 

([X := Y{0}] [shift Y] M <-> MO JS }} . 
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crl [Conv6] : {{ (M <-> N) JS }} => 

{{ (whnf(M) <-> N) JS }} 

if M : WhReducible . 

crl [Conv7] : {{ (M <-> N) JS }} => 

{{ (M <-> whnf(N)) JS }} 

if N : WhReducible . 

We use two auxiliary judgements to formalize side conditions: 

rl [Sort] : {{ (s Sort) JS }} => {{ JS }} . 

rl [Rule] : {{ ((sl,s2,MV) Rule) JS }} => 

{{ (MV = Rules (si, s2)) JS }} . 

Each inference rule of OUPTSs gives rise to a rewrite rule obtained by re- 
versing the direction of inference: 

rl [Ax] : {{ (G I- s ->: MV) JS }} => 

{{ (MV = Axioms (s)) JS }} . 

crl [Lookup] : {{ (G |- X{m} ->: MV) JS }} => 

{{ (MV = lookup (G,X{m>)) JS }} 
if lookup(G,X{m}) . 

rl [Pi] : {{ (G I- {X : A} B ->: MV) JS }} => 

{{ (G I- A ->: ?(NEW1)) (?(NEW1) Sort) 

(G, (X : A) I- B ->: ?(NEW2)) 

((?(NEW1), ?(NEW2), MV) Rule) JS }} . 

rl [Lda] : {{ (G |- [X : A] M ->: MV) JS }} => 

{{ (G I- A ->: ?(NEW1)) (?(NEW1) Sort) 

(G, (X : A) I- M ->: ?(NEW2)) 

(MV = {X : A} ?(NEW2)) JS » . 

rl [Appl] : {{ (G I- (M N) ->: MV) JS }} => 

{{ (G I- M ->: ?(NEW1)) (G |- N ->: ?(NEW2)) 

(G I- (M ->: ?(NEW1))(N -> : ?(NEW2)) ->: MV) 
JS }} . 

rl [App2] : {{ (G I - (M -> : {X : A} B) (N -> : A’ ) -> : MV) 

JS }} => 

{{ (A <-> A>) (MV = [X := N] B) JS }} . 

The terms ?(NEW1) and ?(NEW2) above denote fresh metavariables. Hence 
rewriting has to be controlled by a simple strategy^ that constraints the possible 
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rewrites by instantiating the variables NEWl and NEW2 only with fresh names each 
time a rule is applied. Notice that, in contrast to ordinary variables, where names 
are taken seriously, we abstract from (i.e. we do not care about) metavariable 
names, since they do not have a formal status inside UPTSs, but belong instead 
to the metalevel which is partially made explict in the operational refinement. 

According to the explanations given before, the new judgements have certain 
closure properties w.r.t. =f}. The following simplification rules allow us to work 
with (partially) normalized judgements in the inference rules: 



crl [Norml] : {{ (T Sort) JS }} => 

{{ (whnf(T) Sort) JS }} 
if T : WhReducible . 

crl [Norm2] : {{ ((A,B,T) Rule) JS }} => 

{{ ( (whnf (A) ,B,T) Rule) JS }} 
if A : WhReducible . 



crl [Norms] : {{ ((A,B,T) Rule) JS }} => 

{{ ( (A,whnf (B) ,T) Rule) JS }} 
if B : WhReducible . 



crl [Norm4] : 


{{ 


(G 


1- (M ->: A) (N ->: B) -> 


: T) JS 


}> => 




{{ 


(G 


1- (M ->: whnf (A)) (N ->: 


B) ->: 


T) JS }} 




if 


A : 


WhReducible . 







This completes the definition of the type-inference system for judgements 
of the form F \- M -> : A. Type checking is reduced to type inference in the 
standard way, that is, T h M : A is verified by first checking if A is a type 

in r, and if this is the case we then check if A and the inferred type of M 

are convertible. Exploiting the fact that in PTSs without top sorts each type is 
contained in some sort, this can be specified by the rule 

rl [Aux] : {{ (G I - M : A) JS » => 

{{ (G I- A ->: ?(NEW1)) (?(NEW1) Sort) 

(G I- M ->: ?(NEW2)) (?(NEW2) <-> A) JS » . 



This rule can be slightly optimized by using an adaption of Lemma 3 from 
[42], which allows us to omit the goal (?(NEW1) Sort) on the right hand side, 
since it is implied by the remaining goals. 

Finally, we add rules to check the context typing judgement and the main 
typing judgement: 

By a further refinement of the present specification we can obtain a system with 
takes even metavariables seriously, but this is not necessary for the purposes of this 
paper. 
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rl 


[Ctxtl] 


: {{ 


(emptyContext 


1 I-) JS }} => {{ JS }} 


rl 


[Ctxt2] 


: {{ 


(G, (X : A) II- 


-) JS }} => 






{{ 


(G 1 I-) (G 1- 


A ->: ?(NEW)) 








(?(NEW) Sort) 


JS }} . 


rl 


[Main] : 


{{ 


(G 1 1- M : A) 


JS }} => 






{{ 


(G 1 I-) (G 1- 


M : A) JS }} . 



endm 

Again we have omitted the straightforward rule corresponding to Simple, 
which allows us to check derivability of typing judgements _T Ihi M : A that 
disallow multiple occurrences of the same variable in F . 

To verify a judgement J we start with an initial configuration {{J}}. Either 
this configuration can be reduced to {{emptyJudgementList}}, meaning that 
the judgement has been proved, or the final configuration contains unsolved goals 
giving an informative indication of an error. 

Notice that we have not only used inductive definitions to specify PTSs and 
UPTSs logically, but that, in addition, the operational version of UPTSs given 
by the rewrite rules above is an inductive definition of a labeled transition system 
which gives us a more refined view of the type-checking process. 

The most important property of a type checker is soundness, i.e., each judge- 
ment that has been verified should be derivable in the type system. In fact the 
formal system has been defined in such a way that the soundness of each of the 
rewrite rules above relative to OUPTSs can be verified by straightforward in- 
spection of the rules using the meaning of all auxiliary judgements given earlier. 

More precisely, let S range over decidable, normalizing, functional, full PTS 
signatures without top sorts. We denote by ROUPTS 5 the entailment system in 
which sentences are rewrites of the form {{ JS'}} — > {{ JS"}} and such a rewrite 
is derivable iff it is derivable in the rewrite theory that has been presented above. 
Then the next proposition gives a sound and complete total correspondence 
OUPTSs o ROUPTSs. 

Proposition 45 (Soundness and Completeness of ROUPTSs) 

Let M,A be UPTS terms, let T be a UPTS context, and let J be one of the 
judgements F \\~, F \\- M : A, or F \\-i M : A. If the rewrite {{T}} — > 
{ { empt y Judgement 

List}} is derivable in ROUPTSs, then J is derivable in OUPTSs and vice 
versa. 

Proof Sketch. The soundness part follows from the simple observation that 
for each ROUPTS rewrite rule the right hand side together with its possible 
condition implies the left hand side under the intended logical interpretation 
given earlier. The completeness part can be obtained by adapting the inductive 
proof of Lemma 29 in [52]: Instead of the conventional notion of terms and 
substitution we have to use CINNI syntax with explicit substitutions, and instead 
of of PTSs we have to use OUPTSs. □ 
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Executability in the following proposition means that the structural equa- 
tions are implementable and the remaining equations and membership axioms 
satisfy the standard variable restriction [13,14]. Since we are interested in com- 
pleteness of the operational semantics of rewriting logic for the specific goals 
relevant in our application, we also verify a number of sufficient conditions that 
are further explained in [37,11,13]. 

Proposition 46 (Executability of ROUPTSs) 

The ROUPTS specification is executable, sort-preserving, equationally conflu- 
ent, and coherent. Furthermore, the underlying membership equational theory 
is partially terminating in the sense that all membership, equational, and reduc- 
tion goals, satisfying the condition that whnf is applied only to representations 
of weak head normalizing UPTS terms, are terminating. 

Proof Sketch. Sort-preservation can be easily checked by inspection of each 
equation. To verify confluence observe that the entire equational specification 
is orthogonal and has three subspecifications: (1) the specification of explicit 

substitutions [shift_], [lift ], and their application , (2) the 

specification of metavariable substitution <_ : =_>_, (3) the specification of whnf, 
and (4) the specification of lookup. Orthogonality of (2) and (4) is obvious, 
because there are no critical pairs, and orthogonality of (1) and (3) follows 
from the fact that critical pairs can be eliminated by a simple transformation, 
because their conditions are unsatisfiable. Furthermore, there are no critical pairs 
between (1), (2), (3), and (4), so that we can conclude that the membership 
equational theory is orthogonal and hence confluent. Similarly, coherence of the 
entire rewrite theory follows from the absence of critical pairs between equations 
and rules. 

Finally, we show partial termination of the membership equational theory, 
that is termination of all membership and reduction goals under the condition of 
the proposition. Termination of membership goals M : WhNf and M : WhRedu- 
cible follows by structural induction over the terms M . For the remaining ter- 
mination proof we again exploit orthogonality of our specification, which implies 
that it is sufficient to prove termination under an innermost reduction strategy 
[38]. We use the following strategy: Given a reduction goal M or G, we repeat 
the following two steps as long as applicable: (a) We reduce it to normal form 
w.r.t. (1) if this form has not been reached yet, and then (b) we select an arbi- 
trary innermost occurrence of whnf or lookup and apply one the equations from 
(3) or (4), respectively. Termination of this strategy follows from termination of 
Step (a), which holds according to the strong normalization property of CINNI 
proved in [47,48], and from the fact that whnf and lookup are either eliminated 
in Step (b) or replaced by corresponding occurrences with smaller measures. For 
whnf(M) the measure is the minimal number of /3-reduction steps necessary to 
reach the weak head normal form from M, and for lookup(G, X{m}) the mea- 
sure is the length of the context G. □ 

A remarkable property of our specification is that it can be executed effi- 
ciently in the sense that we do not need an exhaustive search to verify whether 
^ {{emptyJudgementList}} is derivable in ROUPTSs. Instead, we 
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can use a simple execution strategy, i.e. a strategy without backtracking, and 
there is no additional restriction on the strategy beyond the freshness require- 
ment for metavariables mentioned before. In fact, this is a consequence of con- 
fluence and partial termination of the rewrite part of our specification, which is 
stated in the following proposition.^^ 

Proposition 47 (Confluence and Termination of ROUPTSs) 

The ROUPTS specification is rewrite-confluent and partially terminating in the 
sense that all rewrite goals {{oJ}} ^ ?, where J is one of the judgements T Ih, 
r \\- M ■. A, ov r \\~i M \ A with UPTS terms M,A and a UPTS context T, are 
terminating. 

Proof Sketch. Confluence of rewrite rules follows from an analysis of (condi- 
tional) critical pairs. In fact, there is only a single nontrivial critical pair gen- 
erated by the overlapping rules Conv6 and Conv7. Termination follows from 
structural induction over terms using the fact that whnf is only applied to terms 
M for which the goals 

(GII-) (Gl-M: ?(NEW) ) (?(NEW) Sort) 

have been already verified for some context G. As a consequence, M is well-typed 
in ROUPTS 5 , and by the chain of soundness results given in Propositions 45, 
35, and 34, we conclude that M is a-equivalent to a well-typed term in PTS 5 , 
and hence strongly normalizing. □ 



5 Final Remarks 

In this paper we have given presentations of PTSs at different levels of abstrac- 
tion. Moreover, we have discussed very natural representations of these systems 
in MEL or RWL. Both, abstractions and representations are uniformly captured 
by the general notion of correspondence between entailment systems. Our treat- 
ment is guided by the general logics methodology, which explores the space of 
formal systems by using a particular formal system, in this case rewriting logic, 
as a logical framework. Our representations of PTSs range from an abstract 
textbook representation in membership equational logic to a more refined oper- 
ational representation for a subclass of PTSs in the executable sublanguage of 
rewriting logic. 

Apart from its methodological aspect concerned with the use of rewriting 
logic as a logical framework to represent higher-order languages, this paper con- 
tains a more technical contribution, namely uniform pure type systems, a new 
variant of PTSs that provides a solution to the known problem with closure 
under a-conversion in systems with dependent types. Our solution is inspired 
by earlier work of Pollack, who first pointed out the difficulty to obtain closure 

Confluence modulo renaming of metavariables would be sufficient in practice, but it 
happens that, due to the deterministic nature of our specification, we have confluence 
here in the strongest sense. 
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under a-conversion if names are taken seriously. By instantiating our operational 
representation of PTSs, our approach directly leads to an executable prototype 
of the type theory in Maude. In our view the potential of this approach is by no 
means confined to formal representations and prototyping, but we think that it 
provides an interesting alternative to the implementation of type theories and 
typed higher-order logics, which are traditionally conducted using functional 
programming languages such as ML. 

5.1 The Open Calculus of Constructions 

We furthermore would like to point out that the techniques presented in this 
paper have been applied in the development of the open calculus of construc- 
tions (OCC) [48], an extension of the calculus of constructions that incorporates 
rewriting logic and its membership equational logic as a computational sub- 
language. Although OCC deviates quite considerably from the prevailing, more 
conservative line of research in the context of the calculus of constructions, it 
can be seen as a possible realization of the early ideas in [26] on a marriage of 
these different paradigms. 

OCC is a monomorphic type theory with dependent types and universes 
that is considerably more liberal than the calculus of constructions and several 
extensions such as the extended calculus of constructions [29] and the calculus of 
inductive constructions [17], or the calculus of algebraic constructions [9], but it 
maintains its core feature, which is also shared by all the remaining PTSs, namely 
that type checking is ultimately based on a notion of computation. Similar to 
PTSs, OCC is a family of type theories parameterized by a universe hierarchy, 
but we have imposed the requirement that impredicative universes can only 
appear at the bottom of this hierarchy. All other universes are predicative and 
hence form a monomorphic Martin-Lof-style type theory. 

Different from the calculus of constructions, OCC is an open type theory in 
the sense that it is based on an open computational system, which can be specified 
by the user within the bounds provided by its logic. The computational system is 
of similar flexibility as that of membership equational and rewriting logic, which 
means in particular that restrictive operational properties, such as confluence 
and normalization, are in general not enforced by syntactic means. General- 
izing the operational semantics of membership equational logic and rewriting 
logic, OCC supports conditional equations, conditional assertions, and condi- 
tional rewrite rules together with an operational semantics based on a com- 
bination of conditional rewriting modulo structural equations and exhaustive 
goal-oriented proof search. 

Since OCC contains a higher-order equational programming/specification 
language with dependent types, and simultaneously a higher-order logic with de- 
pendent types by virtue of the propositions-as-types interpretation, our approach 
can be regarded as a marriage between the first-order paradigm of executable 
specification languages, such as equational and rewriting logic, and the higher- 
order paradigm, used in functional programming languages and higher-order 
logic proof assistants. Without excluding alternative models, we have equipped 
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OCC with a classical set-theoretic semantics, because it best reflects the pre- 
vailing practice in mathematics and computer science and also facilitates formal 
interoperability with many existing classical logic theorem provers. 

It is remarkable that in spite of its logical and computational expressiveness, 
OCC is a rather minimalistic system based on the combination of only two key 
features: dependent types, and a computational system based on conditional 
rewriting modulo equations. Therefore, it can also be regarded as a natural 
higher-order generalization of rewriting logic. A key rationale behind the design 
of OCC is that an underlying computationally powerful system, like that of MEL 
and RWL, can increase the degree of automation in theorem proving already at 
the level of the formal system, rather than delegating the issue of automation 
entirely to the metalevel by means of tactics. This point is especially important 
for type theories in the line of PTSs, where type checking does not involve the 
use of tactics, but is based on the operational semantics of the type theory itself. 

Using the techniques developed in this paper we have mapped the higher- 
order case to the first-order case, and, not surprisingly, we have employed the 
Maude rewriting engine and its reflective capabilities, to develop an experimen- 
tal prototype of OCC based on this mapping. The prototype, which can be used 
as a programming/specification language and as a interactive proof assistant, 
has been a valuable tool to explore the applications of OCC already in the early 
phase of its development, and has made possible the study of a wide range of 
very different examples in various application domains [48] . In summary, our ex- 
perience indicates that OCC opens a promising new research direction, which we 
hope will contribute to the long-term goal of a unified language for programming, 
specification and interactive theorem proving. 

5.2 Conclusions 

To sum up the main points of this paper, we have shown how a given first-order 
framework can very naturally and directly express powerful higher-order frame- 
works and how binders and substitution can be handled in a fully satisfactory 
way by purely algebraic means. We have also indicated that all this is not only 
of theoretical interest, but that as a fruit of this study, a proof assistant based on 
a new framework like OCC that combines the best of higher-order frameworks 
with the computational flexibility of MEL and RWL has been obtained. 

Although we are interested in more complex applications such as OCC and 
its meta-theoretic properties, in this paper we have focused mainly on PTSs and 
have emphasized the representational aspects. We believe that choices of formal 
representation are important in their own right, and a major issue in applying 
a framework logic like MEL and RWL and in ascertaining the practical value of 
a logical framework. Apart from the benefit of executability that our last spec- 
ification of UPTSs enjoys, a formal specification provides the basis for formal 
metatheoretic proofs. Indeed, MEL and RWL together with their initial model 
semantics provide a very general notion of equational inductive definitions, a 
fact that we exploited for representing several formal systems in this paper. We 
feel that our work is very much in the spirit of Feferman’s first-order approach 
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of finitary inductive systems [19], but by using equational and rewriting logic 
our approach puts a particular emphasis on executability. In fact, an impor- 
tant benefit of our use of rewriting logic, compared with informal presentations 
of algorithms by means of (possibly formal) inductive definitions of derivable 
judgements, is that the algorithms receive a clear formal status as (labeled) 
transition systems, which is the basis to express and reason about operational 
properties such as confluence and termination in a formally rigorous way. 

The general problem of carrying out metatheoretic proofs, soundness and 
completeness proofs being typical examples, often involves the development of 
useful induction principles on the basis of possibly different but related presen- 
tations of the formal system. Such induction principles can be formulated either 
using an internal approach, e.g. by using a formal system such as OCC, which 
contains the framework logic as a sublogic in a suitable sense, or using an exter- 
nal approach, such as the one adopted in Twelf [44], where an external first-order 
logic is added on top of a higher-order logical framework for inductive reasoning 
about the representations. In a certain sense similar to the latter, but avoiding 
its hybrid character, one can instead use a reflective approach (cf. the approach 
to reflective metalogical frameworks presented in [3,4]), which introduces induc- 
tion principles at the metalevel of the representation in a reflective framework 
such as rewriting logic. 
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Abstract. First, we present a simple algorithm which, given a sorted 
sequence of node values, can build a binary search tree of minimum 
height in 0(A) time. The algorithm works with sequences whose length 
is, a priori, unknown. Previous algorithms [1-3] required the number of 
elements to be known in advance. Although the produced trees are of 
minimum height, they are generally unbalanced. We then show how to 
convert them into optimal trees with a minimum internal path length in 
0(log N) time. The trees produced, both minimum height and optimal, 
have characteristic shapes which can easily be predicted from the binary 
representation of tree size. 

Key Words: binary search tree, balanced trees, data structures 



1 Introduction 

The binary search tree (BST) is a well known data structure: it is a binary tree 
with the property that the value of any given node is larger than the node values 
in its left sub-tree and smaller than the values in its right sub-tree. Figure 1 on 
page 377 shows two such trees. In this figure and in what follows, we assume 
integer values for the nodes. 

The height of the tree is an important factor in the analysis of tree algorithms. 
In this paper the height, h, is defined to be the number of nodes on the longest 
path from the root to a leaf. The height of the tree on the left of Figure 1 is 3 
and the height of the tree on the right is 4. The tree on the left with all the leaves 
on the bottom level is said to be perfect. It contains exactly 2^ — 1 nodes. More 
generally, the minimum height for a tree containing N nodes is |log 2 (iV -b 1)|. 
Conversely, the maximum height is N if the tree has degenerated into a list. 

Any modern text on data structures describes the properties of BSTs and 
gives the basic algorithms to find, add or remove an element. Given random 
values, the time complexity of these basic operations is 0(log n); furthermore, 
the values from a binary search tree can be output in sorted order in 0(n) time 
by a simple recursive algorithm shown on page 377. 



O. Owe et al. (Eds.): From OO to FM (Dahl Festschrift), LNCS 2635, pp. 376—388, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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Fig. 1. Binary Search trees 



class Node { 
vType value ; 

Node left, right; 

} 

void printTree ( Node p) 

{ if p ! = null then 
{ printTree (p.left) ; 
print (p. value) ; 
printTree (p. right) ; 

} 

} 



Now consider the inverse operation, namely: building a tree given a sequence 
of sorted values such as produced by printTree. Of course, this can be accom- 
plished by successive INSERT operations but the complexity of this approach 
is 0(7V log N) at best. Actually, if the basic insertion algorithm is used with a 
sorted set of values, the tree degenerates into a list and the complexity is O(fV^). 

In 1976, Wirth [1, p. 195] gave an efficient algorithm to construct a tree of 
N nodes. The algorithm is recursive: a tree of N nodes is built by reading a node 
value and doing recursive calls to build two sub-trees of {N — 1) /2 nodes. The 
resulting tree is perfectly balanced and the running time is 0{N), but the value 
of N must be known before hand. Wirth was not concerned with node order and 
the tree was arbitrarily read in pre-order. More recently, Carrano [2, p. 480, 3, 
p. 545], gives a similar algorithm which works with sorted values but again N 
must be known beforehand. The method is shown below. 

Node buildTree ( int N ) 

{ if N = 0 then 

return null ; 



else 
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{ Node left := readTree ( N / 2 ) ; 
vType value := nextValue () ; 

Node right := readTree ( (N-1) / 2 ) ; 
return new Node( value, left, right ) ; 

} 

} 



In what follows, we develop an algorithm which does the same thing as Car- 
rano’s but does not require prior knowledge of N. This algorithm is presented in 
four steps. First, we start with a simple function which works for perfect trees 
such as shown at the left of Figure 1. This function needs a parameter: h, the 
height of the tree. Second we note, that with a test for end of file, the simple 
function still builds a minimum height tree for any value h greater or equal to the 
correct value. Thirdly, we add a driver routine which builds successively bigger 
perfect trees until the end of data is reached. This driver function requires no 
height parameter and works in 0{N) time. The tree that is built is of minimum 
height and supports the usual operations in logarithmic time but it may not have 
an optimal shape. Finally, we show how to modify the tree to achieve minimum 
internal path length with 0(log N) rotation operations. 

The pseudo-code used for the programming examples is based on Java with 
some Simula (Algol) notation for clarity. The Simula influence can be seen in the 
use of ” =” for equality and ” : =” for assignment and the if . . . then . . . else . . . 
syntax. As in C and Java, we assume that parameters are passed by value and 
that return exits immediately. Finally, in order to make the algorithms match 
the text and easy to follow, we have used more variables and code than strictly 
necessary. 

2 Reading a Perfect Tree 

Given 2^ — 1 ordered nodes values, the function readTree 1 — shown below — 
builds a perfect tree of height h. It assumes that the input contains exactly the 
right number of values and does not check for premature end of data. 

Node readTreel ( int h ) 

{ if h < 1 then 

return null ; 

else 

{ Node left := readTreel ( h-1 ) ; 
vType value := nextValue () ; 

Node right := readTreel ( h-1 ) ; 
return new Node( value, left, right ) ; 

} 

} 
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3 Handling Premature End of Data 

The next version of the input function, readTree2, is identical to the first except 
that we add a test to stop construction when there is no more data to read. We 
assume that the end_of _data test comes before reading and that the test can be 
repeated without error even after it has returned true. The algorithm still needs 
the expected tree height, h, as a parameter but it stops creating nodes as soon 
as the input values are all read. 

Node readTree2 ( int h ) 

{ if h < 1 then 

return null ; 

else 

{ Node left := readTree2 ( h-1 ) ; 
if end_of _data() then return left ; 
vType value := nextValue () ; 

Node right := readTree2 ( h-1 ) ; 
return new Node( value, left, right ) ; 

} 

} 

As long as the data is not exhausted, all trees returned by readTree2 will be 
perfect. Since the algorithm proceeds in order building the left sub-tree before 
the node, the fact that we are able to read a node value implies that end_of _data 
was not encountered during the construction of the left sub-tree/ it is therefore 
perfect; but the same cannot be said for right sub-trees. 

Figure 2 shows what happens, when the initial value of h is correct or larger 
than strictly necessary but there are fewer than 2^ — 1 nodes and end_of_data 
is encountered while building the tree. In the example, there are only 5 node 
values but the function is called with an expected height h = 4. The shaded 
part shows the virtual perfect tree of height 4 (with 15 nodes) which could have 
been returned by the read function. When there are fewer nodes, the algorithm 
traverses this virtual tree in the usual order building nodes with successive input 
value until the end_of _data is reached. Essentially, it fills in the bottom left-hand 
corner of the virtual tree. In terms of execution time, overestimating the tree 
height means that we visit the extra virtual nodes between the root and the 
actual nodes built. 

Essentially, the algorithm tries to build successively taller perfect trees until 
all node values have been read. As long as the initial value of /i > log 2 (A^ -1-1) 
all nodes will be read and the returned tree will be of minimum height but it 
may be unbalanced. The left sub-tree of the root — being perfect — contains 
exactly 2^ — 1 nodes (where h' is the actual height of the tree) but the right 

sub-tree, which contains the remaining nodes, may contain anywhere from 0 to 
2^ — 1 nodes. 
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Fig. 2. Tree returned by readTree2 (4) from values 1, 3, 8, 9 and 11 



4 Dispensing with the Estimated Height Parameter 

To avoid specifying an initial value for the tree height, h, we use a loop which 
calls readTree2 with successively larger values of h to build trees of increasing 
size until the end of data is reached. 

Node readMinTree () 

{ 

int h : = 0 ; 

Node tree := null; 
while not end_of _data() do 
{ 

Node left := tree; 

vType root_value := nextValue () ; 

Node right := readTree2 ( h ) ; 

tree := new Node (root_value , left, right ) ; 

h++ ; 

} 

return tree ; 

} 



In the function tree is the last tree that was built and its height is h. While 
there are nodes to read, tree is a perfect tree containing exactly 2^ — 1 nodes. 
The next larger tree (of height h + 1) uses the old tree as its left sub-tree. The 
next node value is read for the root and we call readTree2 to build a new right 
sub-tree of the same height as the left. If data is still not exhausted, the resulting 
tree is again perfect and we repeat the process until end of data is reached. 

Initially, we start with h = 0 and an empty tree. When the loop terminates, 
the tree built by this function has the same shape as described for readTree2: 
minimum height and a full left sub-tree but a right sub-tree containing anywhere 
from zero to — 1 nodes. 
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Essentially the algorithm does a recursive traversal of the tree that it builds 
and its time complexity is 0{N). 



5 The Shape of Returned Trees 



The trees returned by readMinTree have a definite characteristic shape. While 
the left sub-tree of the root is perfect, the right sub-tree contains at most the 
same number of nodes as the left and generally fewer so the right half of the 
tree is generally not as deep as the left. The same reasoning applies to right 
sub-trees, which will either be balanced or skewed to the left. Overall, the tree 
shape, as shown on page 381, could be characterized as a staircase. 




Fig. 3. Characteristic shape of the trees constructed by readMinTree 



We can get a more precise idea of the tree topology by noting that our tree 
is composed of a succession of perfect trees that decrease in size as they are 
built from left to right and we can think of the nodes on the right edge of the 
tree as a list connecting these perfect trees together. This view will make it easy 
to determine the shape of the tree from the binary coding of N, the tree size. 
Consider the perfect tree of height h shown in Figure 4. It contains 2^ — 1 nodes 
but, if we add the extra link node at the top, the structure accounts for 2^ nodes. 

Thus there is a direct correspondence between the perfect trees in our struc- 
ture and the ones in the binary representation of the tree size. For example, 
consider a tree of 37 nodes: “IOOIOI 2 ” in binary. This corresponds to a tree 
shown below with 3 linked perfect trees whose sizes correspond to the powers of 
2 that add up to 37: 32 -T 4 -T 1. The shape is shown in Figure 5. 
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Fig. 4. Perfect tree component Fig. 5. Staircase of size 37 



6 Improving the Tree 

The time complexity of traditional search tree algorithms is strongly dependent 
on the tree height. In the case of our staircase trees, the height is a minimum 
and equal to |log 2 (A^ + 1)1 so that standard operations can be done in 0{logN) 
time. This height is indicative of worst case operation and compares favorably 
to balanced AVL trees where the height in the worst case is 1.441og(iV + 2) [5, 

p. 118 ]. 

However, for complexity in the average case, the staircase shape is not opti- 
mal. Consider the extreme case when the number of nodes is a power of 2. The 
tree that we return is shown on the left in Figure 6 on page 382. In such a case, 
the right sub-tree is empty and all nodes are in a perfect tree on the left. A 
better disposition of the nodes is shown on the right where all nodes in the left 
sub-tree have been moved up by one level and the root has been moved to the 
bottom. 




Fig. 6. Optimizing a staircase tree 



The tree on the right is an example of an optimal search tree: one in which 
all levels, except possibly for the bottom one, are completely filled. In such a 
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tree, there is no empty slot closer to the root into which a node from the bottom 
could be moved up and the total path length, the sum of the distances between 
each node and the root, is minimized. Note that the improvement in average 
path length to be gained from modifying our trees will be marginal — at most 
one level — as shown in Figure 6. This is because staircase trees are already of 
minimum height and represent intermediate stages between perfect trees whose 
heights differ by one. 

In what follows, we will show how to modify our staircase tree into an optimal 
shape in h steps, where h is the tree height. To do this we will use rotations — 
operations commonly used in AVL trees [4-6] — which move one sub-tree up 
closer to the root while moving another sub-tree down; all the while keeping the 
tree height constant. If the number of nodes going up is greater than the number 
going down, the rotation improves the average path length. 

In Figure 7 on page 383, the tree on the left is typical of the staircase trees 
that we produce. Here X is the root with a perfect sub-tree to its left and a 
smaller tree (i?) to its right. The root Y of the left sub-tree has two equal size 
(perfect) sub-trees labeled L (left) and M (middle). As a result of a rotation, 
the old root X and its imperfect right sub-tree R are moved down one level. 
Y and its sub-tree L move up one level. Y becomes the new root. The middle 
tree, M, is now tied to X instead of Y, but in terms of distances of its nodes 
to the (new) root, nothing has changed and it can be thought of as a fixed 
pivot upon which the other sub-trees balance. Note that the rotation does not 
change the tree height and it maintains the order between nodes and sub-trees: 
L < Y < M < X < R. The important effect is that L moves up whereas the 
smaller R moves down. 




a) before rotation b) after rotation 

Fig. 7. Effect of a rotation 



Another way to consider the effect of the rotations is to note that they modify 
the tree towards the optimal shape by bringing down the smaller imperfect sub- 
tree (i?) on the right until its bottom layer lines up with the bottom of the 
tree. One rotation may not be enough. In the example of Figure 7, after the first 
rotation, R could still move down and we would do further rotations on X. With 
each rotation, R is attached to a lower point in the main (left) tree. When R 
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reaches the bottom, we can start applying rotations to R itself with a view of 
bringing its right half in line with its left. Now for every tree on the right that 

goes down, a tree on the left must go up but you will note in what follows that 

the trees that move up (like L) start on the bottom and go up by only one level. 
Thus these promotions do not destroy the optimal shape. 

Knowing TV, the number of nodes in the tree^, we can compute the number 
of nodes in the various sub-trees and decide if a rotation is warranted: 

— nodes in the whole tree: N 

— height of the tree: h = |"log 2 (iV -1-1)] 

~ height of tree rooted at Y : hL = h — 1 

— size of tree rooted at Y : — 1 

— size of R:nR = N - (2^"i - 1) - 1 = iV - 
~ height of R: hR = [log 2 (ni?-|- 1)] 

An example will clarify the situation. In Figure 8 on page 385, we consider the 
optimization of the staircase tree shown previously. Here, in the initial situation 
(a), N = 37 and h = 6, the heights of the trees on the left and right are 5 
and 3 respectively. A rotation is warranted and the original root along with 
the right sub-tree moves down one level as shown in (b) [the arrow always the 
shows the tree under consideration]. Now, hR remains at 3 but hL = 4 and a 
further rotation brings us to (c). At this point, the right sub-tree is level with 
the bottom of the tree and further rotation of the original right sub-tree is no 
longer beneficial. 

At this point, we skip the rotation but still go down a level to the right to 
see if rotations within the original right sub-tree could be beneficial. Now we 
have N = 5,hL = 2,nR = hR = 1. A final rotation brings us to (d) where 
the rightmost leaf being on the bottom, the work is finished. At each step in 
the optimization process we go down one level, thus the complexity is 0{h) = 
0(log N). 

Going a step further, we can understand the shape of the final tree obtained 
in (d) above by considering that a perfect tree of the same height would have 
contained 26 more nodes than our 37-node tree. In an optimal tree, the missing 
nodes must come from the bottom layer: they are the nodes that would have 
been leaves below our promoted trees. The way we promoted trees was to start 
with the largest on the left, reducing the size by a factor of two at each step. 
Therefore, the gaps from right to left in the bottom layer correspond to the 
binary representation of the missing nodes. In our case: 16 -I- 8 -I- 2 = 26 as shown 
in Figure 9. When comparing figures 8 and 9, remember that the bottom layer 
of a perfect tree with 2^ — 1 nodes contains 2^~^ nodes and that the (missing) 
layer below that would contain 2^ nodes. 



^ These should be counted by the input function next Value and made available in a 
global variable. 
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7 The Optimizing Algorithm 

The code below implements the technique that we have outlined with a slight 
improvement. In the example of Figure 8, we showed how a sub-tree several levels 
above the bottom could be moved down with a sequence of rotations; however, 
it is more efficient to find the node on the right edge below which the sub-tree 
will eventually be placed and do a single rotation at that point. 
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1 Node optimize ( Node root, int N, int h ) 

2 { 

3 if N <= 1 then return root; 

4 

5 int hL = h-1 ; 

6 int nR = N - 2** (h-1); 

7 int hR = ceilingC log(nR+l)); 

8 

9 Node newRoot = root; 

10 if hL > hR then 

11 { 

12 Node leftTree = newRoot = root. left; 

13 hL = hL-1; 

14 while hL > hR do 

15 { 

16 leftTree = leftTree . right ; 

17 hL = hL-1; 

18 } 

19 root. left = leftTree . right ; 

20 leftTree . right = root; 

21 } 

22 root. right = optimize ( root. right, nR, hR ); 

23 return newRoot ; 

24 } 



The method takes 3 parameters: root, a pointer to the root of the staircase 
tree to be optimized; N, the tree size, and h, the tree height. It works recursively: 
on each call, it optimizes a tree by deciding if the right sub-tree should be moved 
down and if so does the demotion; it then proceeds to optimize the right sub- 
tree. The algorithm terminates when the tree has shrunk down to a single node 
(line 3). In the code, we use more significant names, root and leftTree, to 
denote the X and Y nodes of Figure 7. Initially (lines 5-6), we compute the 
size of the right sub-tree, nR, as well as the heights of both sub-trees, hL and 
hR. newRoot represents the root of the optimized tree; it is initialized to root, 
the value that will be returned if no rotation is done. If the right tree is shorter 
than the left (line 10), then the right tree will be moved down and lines 12-18 
determine where it will be inserted. At the same time the value of newRoot is 
changed. The rotation to insert the right sub-tree lower in the left Tree is done 
in lines 19-20. Whether, the right sub-tree has been moved or not, we optimize 
it (line 22) and return the optimized tree (line 23). 

We show below the final version of readTree which combines the optimiza- 
tion with the initial tree building to meet the stated objective: constructing an 
optimal search tree from a sorted set of values. 
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int N; // number of nodes - incremented by nextValue 

Node readTree () // final version 

{ 

int h : = 0 ; 

Node tree := null; 
while not end_of _data() do 
{ 

Node left := tree; 

vType root_value := nextValue () ; 

Node right := readTree2 ( h ) ; 

tree := new Node (root_value , left, right ) ; 

h ++ ; 

} 

return optimizeC tree, N, h ); 

} 

A Java test version of this algorithm is available on the Internet at the 
following URL: http://www.iro.umontreal.ca/~vaucher/Pubs/BST.java 

8 Conclusions 

We have developed a simple algorithm which, given a sorted sequence of node 
values, can build a balanced binary search tree in 0{N) time, without requiring 
a priori knowledge of the number of elements, N. The novel idea is that a 
minimum height tree can be constructed by trying to build successively deeper 
perfect trees, using the tree from the last step as the left sub-tree of the new one. 
It is then a simple — though tricky — matter to reshape the tree with rotations 
to minimize internal path length. We also showed that the shape of the trees 
had a simple one-to-one correspondence to the binary representation of the tree 
size. 

This algorithm could also be used to re-balance an arbitrary tree. Given a 
language with coroutines (like Simula [7]), we could emulate Ole- Johan Dahl’s 
technique from his classic 1972 paper with Tony Hoare [8]: using one coroutine 
object to recursively traverse the old tree and provide input for another coroutine 
using our algorithm to build a better tree. With a current language like Java, 
rebalancing could still be done but would be less elegant. 

I met Ole-Johan Dahl along with his colleague Kristen Nygaard in the early 
1970s on a visit to Oslo to learn more about Simula. The concern with rigor 
and clarity as well as innovation evident in their work over the years has been a 
continuing source of inspiration and I grieve their passing. 
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